Как это работает?
Разгребал завалы кода и попалось такое:
<pre>
...
List<Servers> servers = new List<Servers> {
new Server { Name = "Name_1", IP = "192.168.1.1" },
new Server { Name = "Name_2", IP = "192.168.1.2" },
new Server { Name = "Name_3", IP = "192.168.1.3" },
}
class Server
{
public string Name { get; set; }
public string IP { get; set; }
}
...
</pre>
и ведь работает.
Я понимаю - динамика и т.п. но поля то надо где-то хранить... даже ссылок на них нет.

???

class Server 
{
public string Name { get; set; }
public string IP { get; set; }
}

поля типа стринг "Name" и "IP", каждое с геттером и сеттером?

Это - не поля, это - проперти. Ну или аксессоры. Методы доступа к полям.
get & set - методы, в общем случае - независимые, которые должны быть определены, но они не определяют локальные данные.
Поля для хранения, разделяемые - отдельно.
Именно этот момент и не понятен - где хранятся поля? - можно ли присваивать динамические данные? - сколько времени они валидны?
Читал что-то по поводу того, что .Нет может добавлять поля динамически, но не пользоваться не приходилось.
Инициализация - тоже интересная - нет прямого вызова дефаултового конструктора... но есть присваивания пропертям.

Мур, ты бы азбуку какую-нибудь по ООП почитал сначала, что-ли

Азбуку Я читал. Давно правда. Может и подзабыл чего... чем черт не шутит...
Только вот какая штука. В большинстве случаев код выглядит следующим образом
private string name; // поле
public string Name { get { return name; } set { name = value;} } // проперть
Тут проблем нет, все понятно. Даже понятно, что делается и как выглядит в других языках.
Каким образом создается поле в том примере - не понятно. но где-то оно хранится.

В C# 3.0 появились автоматические свойства - автоматически генерируется приватное поле, также появилась инициализация объекта вместе с его свойствами.
http://msdn.microsoft.com/ru-ru/library/bb384054.aspx

Спасибки - прояснилось. Я пока сидел на 2.0... и немного начал 4.0, но не сталкивался с этим.
"...компилятор создаст закрытое, анонимное резервное поле, которое доступно с помощью методов get и set свойства."
Насколько такая хрень может быть полезна? Вполне можно объявить открытое поле. Если нужно ограничение по доступу - есть readonly. Закрывать по чтению? Так вроде вообще бессмысленно - поле анонимное и читать его нельзя, и запись не контролируется...

Ну, ридонли сделает поле недоступным для записи и для членов класса.

Это - да, упустил, помня об возможности инициировать консты пользуя помещающий синтаксис.
Хотя... где-то там есть методика обхода readonly. Но в случае с пропертью - будет проще.
Надо будет посмотреть, насколько упостится код в какой-нибудь части проекта при использовании этой фичи... Думаю, что все же не слишком - требуется пустой сеттер, что, по большей части, не имеет места быть...
Интересно - подо что они это планировали? По мне так:
obj.Property1 = "dkf";
obj.Property2 = "ufhjk";
string t = obj.Property3;
выглядит предпочтительнее, чем
obj.Property1 = "dkf";
obj.Property2 = "ufhjk";
string t = obj.Calc();
или
obj.Calc();
string t = obj.Property3;
или
string t = obj.Calc("dkf","ufhjk");

Интересно - подо что они это планировали?
---
Быстрое создание "контейнеров данных" без логики. Применять можно по разному,
например часто используется в n-tier системах, или для сохранения результатов LINQ.
или
string t = obj.Calc("dkf","ufhjk");
----
С некоторых пор предпочитаю именно это, если дизайн позволяет. Stateless - со всеми своими преимуществами/недостатками (например потокобезопасность)
obj.Property1 = "dkf";
obj.Property2 = "ufhjk";
string t = obj.Calc();
----
Если при внесении данных в первые два свойства происходит вычисление третьего, то логично использовать string t = obj.Property3;
Если же вычисление происходит в момент обращения, то уместнее все же obj.Calc();
Вообще, провакационный вопрос, и мое мнение может не совпадать с твоим

Как это работает?
---
На такие вопросы часто помогает ответить IL, или рефлектор. Тем более ничего магического тут нет, CLR-рантайм в третьем шарпе используется второй

Быстрое создание "контейнеров данных" без логики.
------
У них и так есть универсальный контейнер данных - DataSet. При том, что даже типизацию можно делать в динамике. И логика, пусть не вся необходимая, присутствует.
Второй момент - класс, как таковой, можно сгенерировать. Со всеми полями, пропертями и частью логики. Тут проблем совсем нет. Проверено.
С некоторых пор предпочитаю именно это, если дизайн позволяет.
-----
Поясни. Дело в том, что там не стателес по определению. Параметры остаются в полях объекта, но изменение - побочный эффект вызова метода. Сие не есть гут.
Если при внесении данных в первые два свойства происходит вычисление третьего
-----
Почему-то всегда стараюсь поддерживать объект в полной готовности. Т.е. пересчитываю сразу как только получил необходимые данные. Есть, конечно, ситуации, в которых на пару тысяч присваиваний и пересчетов приходится один запрос на данные, но это не типично. Но даже если пересчет нужно отложить до обращения к проперти - проблем нет - private Calc() { ... } - доступно объекту, но невидимо пользователю.
провакационный вопрос
-----
- потому можно расмотреть плюсы и минусы. Глядишь что-то поменяется и где-то полегчает...

LINQ
-----
Вопрос по LINQ - отдельный, но на мой взгляд - это скорее зло, чем полезная фича.
Элементарно по-тому, что принуждает писать код а-ля-ВБ... не подлежащий сопровождению.
Можно провоцироваться тут, можно в отдельной ветке.

Гы. Да ну?

int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
var firstNumbersLessThan6 = numbers.TakeWhile(n => n < 6);

// Быстрое создание "контейнеров данных" без логики.
У них и так есть универсальный контейнер данных - DataSet. При том, что даже типизацию можно делать в динамике. И логика, пусть не вся необходимая, присутствует.
---
В моем посте я должен был бы поставить ударение на "без логики". Кстати логику можно всегда будет приписать, но позже
Второй момент - класс, как таковой, можно сгенерировать. Со всеми полями, пропертями и частью логики. Тут проблем совсем нет. Проверено.
---
Не спорю. А может быть автоматические свойства создали для нытиков, которые на отрез отказывались применять Свойства взамен открытым полям ?. Также приятно писать/читать код с минимальным количеством букав
Поясни. Дело в том, что там не стателес по определению. Параметры остаются в полях объекта, но изменение - побочный эффект вызова метода. Сие не есть гут.
---
Согласен, что сие не есть гуд. Я воспринял эту запись как случай отделения логики от данных.
Почему-то всегда стараюсь поддерживать объект в полной готовности. Т.е. пересчитываю сразу как только получил необходимые данные. Есть, конечно, ситуации, в которых на пару тысяч присваиваний и пересчетов приходится один запрос на данные, но это не типично. Но даже если пересчет нужно отложить до обращения к проперти - проблем нет - private Calc() { ... } - доступно объекту, но невидимо пользователю.
---
Здесь вообще очень тяжело выдумывать правила, но когда я работаю с чужим классом, я ожидаю, что get/set проперти не повлечет длительные вычисления. Если это невозможно, то процессом вычисления лучше управлять извне (метод Calc), тогда работу с объектом можно организовать наилучшим оптимальным способом. Также я стараюсь поступать со своими классами.

Да ну?
------
Что-то дает сущность, определяемую как массив (динамический?) целочисленных данных и требуется функциональность получения первого со значением менее "6"?
Почему бы не определить класс и проперть/метод?
Будет нужен набор из всех "меньше\больше Х" - почему бы не сделать отдельный итератор?
Время на имплементацию? см. следующий момент.
Следующий момент - представь себе, что у тебя экстремальный случай - чудовищная форма, с кодом размером 256.000 байт, состряпанная по приведенному тобой примеру. Это вполне реальный вариант при миграции с VB 6.0 с заменой части SQL на LINQ. Каким чудом ты будешь это разгребать? Сколько времени потратишь?

логику можно всегда будет приписать, но позже
------
Я опять немножко не понял. Автоматическая проперть требует пустых сеттера и геттера. Вписать в них функциональность = отказаться от автоматической проперти. Если же имеется в виду добавление имплементаций каких-то интерфейсов, то вроде как билли отказался от этого в пользу имплементации внешних процессоров. Ну типа как запись в базу и т.п.
Т.е. либо пустое типизированное хранилище, что легко делается через DataSet, либо отказываемся от фичи.
на отрез отказывались применять Свойства
-----
Это полиси в компании.
У меня было пару раз, что писали с открытыми полями. И менять методику - не хотели. Подобрал методику, весьма простую - передавал на доработку другому, и потери времни все быстро исправили. Так что - не аргумент.
Также приятно писать/читать код с минимальным количеством букав
------
Да, это - аргумент. Будь моя воля, Я бы совместил определение пропети и определение поля. Что-то типа:
private String myProperty; // только поле
public String MyProperty { get {...} set {...} }; // чистая и/или автоматическая проперть
public String MyProperty { get {...} set {...} } myProperty; // проперть и приват поле
Вроде никаких неоднозначностей не вносится и абстрактность не страдает.
Можно, в принципе, сделать еще проще - поля, как таковые, всегда иметь приват или протектед, а рядом определять паблик сеттеры и геттеры. Но тут пострадает абстрактнось - проперть нужна сама по себе. Так что - доопределять поле правильнее...
Но все же есть регионы - лишний на данный момент код можно убрать.
Я воспринял эту запись как случай отделения логики от данных
-----
Был бы статический метод... и вызов через тип.
процессом вычисления лучше управлять извне (метод Calc)
-----
Думаю, что нет. Основания - все та же ООП - процессом вычисления должен управлять сам объект.
Организация управления - достаточно тривиальная - новый поток для продолжительного вычисления, пулл потоков для оптимизации загрузки, синхронизация (если не успело вычислится - жди - как и с вызовом Calc) для выдачи результата в проперть.
Также я стараюсь поступать со своими классами.
-----
Годик назад повозился с потоками. Результат говорит, что если есть готовность использовать потоки - надо их использовать. Как раз для этих целей. Готовность в данном случае - по квалификации и по времени имплементации. Время там возрастает примерно вдвое и аккуратность требуется куда как более высокая, чем при автопропертях... Но работает - на раз.

Оторванная ото всего - ничего. И получется не первое значение, а массив значений. Если же не заниматься выяснением, зачем понадобился срез именно этого массива, а посмотреть на пример как на демонстрацию мощи LINQ- a, показывающий, что оно умеет делать выборку из абстрактного источника данных используя предикат, то можно увидеть, что делается это в _удобной форме_. LINQ - это удобство прежде всего.

Ну, итератор и срез вещи не взаимозаменяющие друг друга. Если вы спрашиваете, почему сделано в функциональном стиле, а не в стиле ООП, то различного рода манипуляции со списками удобнее делать чаще именно в функциональном стиле, без неестественного огорода с нехилым синтаксическим оверхедом в виде ООП.

Во-первых, притянуто за уши. Я пример как раз кинул такой, чтобы сказать, что LINQ, это не только LINQ- запросы к источнику данных связанному с БД.
Во-вторых, с "запросы в коде = однозначно неправильно" я не согласен. Есть огромное число задач сводящихся к примитивной работе с данными: выборка, вставка, апдейт, удаление и LINQ очень удобен тем, что заменил посторонний SQL, неестественно торчащий из кода, привычным нативным языком программирования со всей его мощью, с проверкой типов во время компиляции, с интелсенсом, наконец.
В третьих, замена SQL на LINK достаточно прозрачна, можно почти один-в-один заменять, если брать абстрактную замену SQL на LINQ, если же брать конкретно вашу сгенерённую хрень, с которой уже никак иначе нельзя удобно работать, кроме способа используемом вами, то и при использовании LINQ можно тоже автоматизацию какую-нибубдь придумать для сложных проектов.

LINQ - это удобство прежде всего.
-----
С этим не согласится сложно. Примерно то же заявлялось при выпуске Аксесса - SQL по месту и оптимизация на системном уровне. Оказалось, однако, что задачу, состоящую из более 10-ка форм, сопровождать практически невозможно.
что оно умеет
-----
Помимо этого надо думать об том где и как применять и какой оверхед времени исполнения будет.
Место применения, как Я понимаю, как раз внутри объекта... где, в принципе, не слишком существенно что именно используется.
Ибо как только сие начинает применяться произвольно, то вылазят проблемы где их не надо.
И получется не первое значение, а массив значений.
итератор и срез вещи не взаимозаменяющие друг друга.
-----
Тем хуже. Ибо если возвращается массив, то хотелось бы иметь его во врапированном виде с корректными индексерами. Если этого нет, то итератор более приемлем.
удобнее делать чаще именно в функциональном стиле,
------
Удобнее. Честно говоря - почти все удобнее делать в функциональном стиле. Тем не мение объемы вынуждают работать в ООП с его оверхедом.
с нехилым синтаксическим оверхедом в виде ООП.
-----
Синтаксический оверхед меня беспокоит мало - это всего лишь время работы разработчиков с достаточно невысокой квалификацией. При правильном подходе - изменения трекируются без особых проблем. LINQ же предлагает смешивать Функциональный и Объектный подходы в одном и том же решении, что не есть хорошо по определению. А удержать разработку в одной концепции будет много сложнее, со всеми вытекающими последствиями.
притянуто за уши.
-----
Не совсем - у меня были формы такого размера в VB6.0.
это не только LINQ- запросы к источнику данных
-----
Потому Я и указал - частичная замена SQL to LINQ.
с "запросы в коде = однозначно неправильно" я не согласен
-----
Что проще
- код, в котором идет работа с объектом, без привязки к источнику данных
или
- код, манипулирующий источником данных через объект и напрямую?

С точки зрения сопровождения - зпросы в коде однозначно есть зло.
Другое дело, что для разработки дешевой поделки основную роль играет не сопровождение, а разработка - чем быстрее, тем лучше. Но тут есть возможность (полу)автоматизации...
можно почти один-в-один заменять
-----
Именно об этом Я и писал выше - приложение на VB6.0 и миграция на VB.Net & LINQ. Остается стиль VB-приложения и издержки на его сопровождение. Это выглядит скорее как большой минус для LINQ.
с которой уже никак иначе нельзя удобно работать
-----
А в чем проблемы? Обычный код. Можно наследоваться и перегружать все что душе угодно. Единственное, что дает генерация - работоспособный объект, имеющий определенный набор функциональности. Набор функциональности, вероятно, не самый лучший и не самый широкий, но достаточный для работоспособности приложения. На моей памяти его было достаточно для работы и меняли в нем что-нибудь редко.
при использовании LINQ можно тоже автоматизацию какую-нибубдь придумать
-----
Наконец высказано желание того, что надо бы рассмотреть область применения LINQ.
Я не против LINQ как такового. Даже в определенной мере - ровно на столько, на сколько он не выпадет из ООП - ЗА. Например та же подвыборка для значений меньше 6 - пусть у объекта будет проперть, возвращающая эту подвыборку, и пусть имплементация оной будет сделана на LINQ вместо итератора (там где заменяемо) - я ЗА. НО Я категорически против применения того же LINQ "поверх" объекта, где он, в основном, и будет применяться.
P.S. Тот объект, что у меня генерируется, Я планирую менять - много чего не устраивает...

выборка, вставка, апдейт, удаление
-----
Что-то типа такого должно решить проблему:
TBusinessObject bo = new TBusinessObject();
bo.Filter = new TFilter( .... ); // или TFilter fl = bo.NewFilter;
bo.Load(); // в соответствии с фильтром
TMyTable1 mt = bo.MyTable1;
mt.DeleteAllRows(); // или перебор для всех строк с удалением
mt.NewRow( ... );
bo.Save(); // актуализация БО и ДБ или что там за хранилище...
Эээ... указанный интерфейс - SUDI - у меня используется между БО и ДБ - база предоставляет 4 процедуры... и не позволяет выполнять прямой SQL.