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

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

LM>>TaxRow это представление одной записи в базе данных. Грубо говоря RecordSet типизированный. BusinessEntity делегирует некоторые поля из него.
MVK>А для чего он тебе нужен? Если ты решил использовать BusinessEntities, то почему результат запроса в базу не меппить сразу на твой Tax минуя типизированные рекордсеты? И, кстати, что остается с полями, которые TaxRow не делегирует?

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

Поля которые BusinessEntity не делегирует, просто не изменяются и сохраняются в базу как были.

LM>>Для того чтобы сохранить BusinessEntity в базу данных надо иметь доступ к этому рекордсету, вот для этого и сделана эта проперти.
MVK>Опять же, почему не сохранять в базу сам Tax минуя типизированный рекордсет?

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

MVK>P.S. Тебе нужно просто определиться: или ты используешь типизированные датасеты или используешь бизнес сущности. Смешение подходов ни к чему кроме путанницы не приведет.

Дело в том, что вся эта кухня варится в рамках legacy проекта, кде использовался подход типизированного рекордсета. Ни к чему кроме матов это не привело (проекту два года).