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

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

Зачем ? Хм, могу предложить ситуацию из моего реального проекта. Система по учету производства деталей. Имеется набор деталей, каждая из них имеет технологию производства, причем одна и та-же технология может быть задействована в нескольких деталях. Пользователь загружает набор деталей для просмотра. Разумеется, время от времени в одном наборе деталей оказываются детали с одинаковой технологией.
А теперь смотри — пользователь отредактировал технологию детали А. Потом переключился на деталь Б, имеющую эту-же технологию. Но из-за того, что деталь Б имеет другой объект Технология (хоть и с одним ID), он увидит старую неотредактированную технологию.
Может это и не конец света, но очевидно баг программы. И никакие Equals() здесь не помогут

A>А удобно на каждый чих создавать свой собственный типизированный DataTable?
ну не на каждый чих, а на каждую таблицу с результатами поиска

A>Один класс DataRow, второй -- Client.
а причем здесь тогда размазывание сущности по двум классам и интерфейсам

A>В моем понятии кэш это когда мы что-то храним чтобы не обращаться лишний раз к БД (например). А то про что ты говоришь это Identity Map.
A>См выше. про Equals()
в моем понятии кэш сочетает в себе все эти достоинства.

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