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

LM>BisinessEntity это очень сложная сущность, которая может содержать кучу других сущностей. Например Заказ может содержать список Товаров. Маппер знает как взять строку заказа и строки Товаров из базы данных, и соединить их в единую BusinessEntity Заказ.
Пусть содержит. Пусть у маппера есть метод, который по id заказа возращает тебе полноценную BE с вместе с товарами. В чем трудности то?

LM>Поля которые BusinessEntity не делегирует, просто не изменяются и сохраняются в базу как были.
Опять таки, я не вижу проблем. Если это, например, служебное поле в базе заведенное там с целью оптимизации каких нибудь внутрибазовых операций — то просто его не вытаскиваешь и все. Если это поле не может изменяться, ну просто не делаешь у него сеттер и все.

LM>Смотри выше. TaxEntity на примере о4ень простой, из-за того, что это просто пример. В реальной жизни он будет содержать к примеру еще процентную ставку как бизнесСущность. Напрямую это замапить на DB дело неблагодарное.
Вот я непонимаю, почему? У всех все меппиться и без особых проблем. Ты можешь привести пример реальной BE и табличек в базе и посмотрим в чем трудности меппинга.

LM>Дело в том, что вся эта кухня варится в рамках legacy проекта, кде использовался подход типизированного рекордсета. Ни к чему кроме матов это не привело (проекту два года).
Довольно трудно будет вам сменить подход. Идеальный вариант — это найти способ изолировать всю вашу кухню от нового кода. Т.е. не мешать BE и датасеты в одном месте, т.к. вы фактически свяжете вместе два подхода.Если такой возможности нет, я бы десять раз подумал о смене подхода.