Здравствуйте, Aikin, Вы писали:

A>P.S. Зарегся, плиз. Всего 5 минут, а люди будут знать с кем общаются

Done

A>Еще раз повторяю: если задача позволяет (нет логики в данных), то лучше DataTable я не знаю.
A>Вот только круг задач где к данным не примешивается логика очень узок. Для отчетов это подходит, а для изменения данных (не тупого редактирования через грид) нет.

что значит логика в данных ? Я имел ввиду следующую ситуацию — пользователь хочет найти некий объект (клиента например), и что-то с ним сделать. Он вводит в фильтр имя клиента (или телефон, e-mail итп) и получает соответствующий набор строк в гриде на экране.
Далее жмет кнопку Выбрать, в результате появляется окно редактирования выбранного клиента. Понятно, что окно с редактированием будет пользоваться именно доменной моделью Клиента, а не строкой DataRow. Для этого на основе выбранной строки (идентификатора) я создам объект Клиент. А вот зачем создавать тысячу объектов Клиент на основе полученных данных для показа в гриде мне непонятно.

A>Все равно не понимаю в чем существенно в плане потребления памяти отличаются доменные объекты от дататэйбла?
A>Ну допустим, даже, у нас есть 20% оверхэд памяти. Неужели это так критично? И стоит поплатиться удобством программиста и ясностью кода?

тем, что материализованные объекты нужно будет кэшировать. А набор DataRow изчезнет как только окно с ними будет закрыто (точнее когда до них уборщик мусора доберется). Так что да, для больших баз может вполне оказаться критично. Этак в течении рабочего дня вся база может плавно перетечь в оперативную память клиентской машины
Да и удобства программиста какие-то сомнительные, писать реализацию сортировки/фильтрации и разнообразные SomeObjectInfo имхо не очень удобно

A>Т.е. получается что размазываешь физическую сущность на два класса. При добавлении нового поля менять придеться два класса, у тебя будут два варианта интерфейса (один работает с таблицами, другой с объектами)...
A>Что-то я сомневаюсь, что поддержка такой параллельной архитектуры обоснована сомнительным выигрышем в производительности и потреблении памяти (проблем с которыми, скорее всего, нет).

тут уже я не понял, откуда у меня 2 класса возьмется. Класс домена Клиент один. Его объект я сформирую либо прямо на основе данных в текущей строке DataRow, либо выполнив запрос к БД, используя ID клиента опять-таки текущей строки DataRow.

A>Ниразу нелогично. Кэшировать нужно только то, что действительно часто вызывается. А не все подряд. Ибо проблемы с актуализацией кэша не так уж просты. (Не хочу спорить про кэш, ибо это необхватная тема).

что значит "действительно часто вызывается" ? Как это ты определяешь-то, часто что-то вызывается, или нет ? Имхо, польза кэширования не столько в том, что-бы сэкономить обращение к БД (хотя и оно тоже конечно), сколько в том, что-бы не допустить наличия двойников одного и того-же объекта. А раз объект был материализован, значит вполне логично сложить его в кэш, что-бы разные части системы могли гарантированно работать с одной и той-же копией объекта.

A>Ничего не понял, но, ИМХО, ты драматизируешь.

ну вот смотри — обратился я к реестру объектов Клиент с запросом отдать мне всех Игорей. Вернулось 1000 игоревых объектов, причем в кэше для экономии памяти мы их не закэшировали. Я выбрал Игоря с ID = 455, и сложил куда-нибудь себе для дальнейшего пользования. Теперь я обратился к кэшу с запросом отдать мне всех клиентов, живущих в определенном районе, причем Игорь с ID = 455 тоже туда попал. Так как кэш отсутствует, то реестр мне создаст еще один объект Игорь c ID = 455. Итого я получил два разных объекта Игорь, хотя на самом деле это один и тот-же клиент.

A>Опять "материализовать". Да эта операция занимает сотые секунды! Да нет почти никакой разницы что собирать объект или DataRow. Все одно: Get/Set/Get/Set/...
A>DataRow собирается автоматом, а объект нужно самому? Используй ORM движки (nHibernate, например, или LINQ to SQL от майкрософта) он все сделает за тебя.
A>Тем более с использованием O/R движков ты получаешь кучу фич из коробки (LazyLoad, кэш и многое другое).

я вообщем-то не особо спорю с тем, что создать объекты можно быстро. Как я уже написал, основные проблемы в другом месте. Но тем не менее обрати внимание, что помимо сотых долей секунды, для этого также потребуется собственно реализация разнообразных сортировок/фильтраций и SomeObjectInfo, что усложняет систему на совершенно ровном месте.