Если следовать советам Крэга Лармана (и по всей видимости далеко не его одного), бизнес-классы не должны отвечать за сохранение себя в БД (т.е. обладать методами сохранения в БД и материализации из нее), так как это приводит к смешиванию их обязанностей с обязанностями технических служб.
Одним из предлагаемых им методов является создание для каждого бизнес-класса специального класса-преобразователя, который и отвечает за материализацию/дематериализацию объектов, причем для повышения абстракции предлагается создать еще один класс, который будет содержать только операторы SQL, т.е. этот класс вызывает хранимую процедуру на сервере, получает набор записей из БД, передает их классу-преобразователю, который на их основе и синтезирует объект бизнес-логики.
Причем каждый бизнес-класс также имеет свойства состояния (т.е. например New, OldClean, OldDirty в зависимости взят-ли экземпляр только-что из БД или синезирован совершенно новый, изменен-ли и т.п.)

Как вообще правильно работать со всей этой кухней ? Сам Ларман причем в конце пишет, что вообще-то никто не мешает пойти другим путем, и все-таки унаследовать бизнес-классы от технического предка, если это "приводит к простому и прозрачному решению". Только вот не уточнаяет критерии прозрачности, что это, количество классов что-ли ? И каким способом тогда определять, много их уже или еще нет ?
А что делать, если необходимо вывести dataGrid с табличными данными, скажем, деталей определенной машины ? Ну неужели получать коллекцию объектов деталей, а затем по-одному записывать в строчки грида ? Или тут идет на компромис, типа для грида делаем исключение, и засасываем записи напрямую не рассматривая их как набор объектров ?

Может у кого-нибудь есть хорошие ссылки по теме, или даже электронные книжки, посвященные этой тематике ?

Если это Model View Controller - то что-то не понял, что именно вы хотели этим сказать