S>Далее жмет кнопку Выбрать, в результате появляется окно редактирования выбранного клиента. Понятно, что окно с редактированием будет пользоваться именно доменной моделью Клиента, а не строкой DataRow. Для этого на основе выбранной строки (идентификатора) я создам объект Клиент. А вот зачем создавать тысячу объектов Клиент на основе полученных данных для показа в гриде мне непонятно.
Для меня нет большой разницы между DataRow и Client (из домена) и тот и тот будет требовать примерно одинаковое количество ресурсов. Разница только в том, что к Client можно добавить логику, а к DataRow нет.

S>тем, что материализованные объекты нужно будет кэшировать. А набор DataRow изчезнет как только окно с ними будет закрыто (точнее когда до них уборщик мусора доберется). Так что да, для больших баз может вполне оказаться критично. Этак в течении рабочего дня вся база может плавно перетечь в оперативную память клиентской машины
Да брось ты с этим кэшированием. Зачем? Ну и что что у нас будет два разных объекта представляющие одного клиента, кто тебе сказал, что это конец света?
Что мешает переорпеделить Equals() чтобы при сравнении программа знала что это один и тот же объект?
Отработавшие же объекты так же оставляются на съедение гарбидж коллектору.

S>Да и удобства программиста какие-то сомнительные, писать реализацию сортировки/фильтрации и разнообразные SomeObjectInfo имхо не очень удобно
А удобно на каждый чих создавать свой собственный типизированный DataTable? Или, может, дататэйблы у тебя вообще нетипизированные?

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

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

S>Так как кэш отсутствует, то реестр мне создаст еще один объект Игорь c ID = 455. Итого я получил два разных объекта Игорь, хотя на самом деле это один и тот-же клиент.
См выше. про Equals() Который чаще всего использует ID для сравнения.

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

В общем советую просмотреть код проекта сделанного на NHibernate (советую тут (Enterprise NHibernate Sample) просмотри DAO и Domain все остальное это ASP .net на MVP), ИМХО, просто, понятно и действительно меньше лишних телодвижений.