Здравствуйте, Козьма Прутков, Вы писали:

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

Весьма распространённое и в то же время ошибочное мнение, которым обычно прикрывается либо кривой дизайн базы либо объектной модели. В процессе разработки модель данных и структура базы могу и должны соответствовать друг другу. Вот ты мне можешь привести живой хороший пример, когда различия в структуре базы и модели заложены в дизайне? Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.

КП>Из этого делаем совершенно тривиальный вывод, что имеет смысл вынести этот расчет в БД, как говорится "move processing to data, not data to processing".

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

КП>Теперь давайте забудем о мепперах, ибо это понятие всех путает. Меппер предназначен для того, что ОТОБРАЗИТЬ данные БД в модель предметной области. Сам объект остается В ПОЛНОМ НЕВЕДЕНИИ о существовании этого меппера. Об этом знает прикладной код, который загружает объект по необходимости, сервисный слой (как у IT) и прочая. БО ничего не знает о DAL, совсем, я думаю и о сервисном слое тоже, разве что о реестре каком-нибудь, но это отдельная песня.

Здесь мы тоже имеем терминологическую путаницу. БО в классическом понимании ООП — это объект несущий в себе как данные, так и логику. Если эти две вещи разделять, то нам нужны новые термины, иначе мы можем начать называть одним термином разные вещи, ты будешь подразумевать под этим бизнес-сущность, а я сервисный объект.