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

A>>Сборка объекта не стоит ничего по сравнению с обращением к базе.
A>>Про идентефикаторы ничего не понял
A>>В большинстве случаем память занимаемая объектом == памяти занимаемой всеми его частями (ну может еще несколько байт, но это фигня).
А>Вот смотрите, требутся пользователю найти клиента (что-бы отредактировать или что-нибудь в этом роде) — вводит в фильтр имя Игорь, и в ответ ему из БД приезжает 1000 записей с Игорями. Зачем мне материализовывать всю тысячу ?
А>Из них он выберет только одну запись (на самом деле конечно просто введет еще одно условие фильтра, так что вся эта тысяча объектов вообще будет не нужна),
Все равно не понимаю в чем существенно в плане потребления памяти отличаются доменные объекты от дататэйбла?
Ну допустим, даже, у нас есть 20% оверхэд памяти. Неужели это так критично? И стоит поплатиться удобством программиста и ясностью кода?
С другой стороны, ты что собрался эту всю тысячу показывать? А где же пэйджинг?

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

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

А>Если-же их не кэшировать, то что-то слабо представляю, как это все будет работать — получили 1000 записей из БД, материализовали, получили смесь из новых объектов, не подлежащих кэшированию, и "старых" объектов, которые уже были в кэше. Отдали эту гремучую смесь клиенту, который возьмет и сохранит часть этих объектов. Потом он делает новый запрос к реестру, получает еще тысячу объектов, у части которых уже есть клоны ... В общем муть какая-то получается
Ничего не понял, но, ИМХО, ты драматизируешь.

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

A>>И все же хочу уточнить, что я не против ДатаТэйблов. Когда нужно просто посмотреть и отредактировать данные по скорости и удобству (поддержка .Net) им нет равных, но вот когда в просмотр и редактирование вкрадывается логика... Лучше сразу от них отказываться (ИМХО).
А>а ведь нету никакой особой логики-то, получили список искомых записей, выбрали нужную. Зачем нам для этого объекты ?
Вот я и говорю что незачем. Для отчетов они не нужны Но это если они идут отдельной частью системы. А лучше в отдельной DLL. Чтобы не было желания добавить к ним логику: "я чуть-чуть, это будет элементарная логика".

P.S. Зарегся, плиз. Всего 5 минут, а люди будут знать с кем общаются
P.P.S. И давай на "ты", что-то меня "выканье" коробит .