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

_>Вот такая упрощённая логика. Для расчёта требуется дополнительная информация, но в зависимости от промежуточных результатов. Каким образом построить меппары, бизнес объекты, что-бы зависимость между ними была минимальна.

Всё очень просто.

Бизнес сущности. Классы описывающие предметную область: Company, CompanyNegativeInfo и т.п. Желательно, что бы эти классы совпадали со структурой таблиц БД. В этом случае маппинг можно сдлать абсолютно примитивным, что существенно упростит DAL. В зависимости от общей архитектуры бизнес сущности могут быть вынесены в отдельный проект.

Бизнес логика. Сервисы или менеджеры (как больше нравится). Всё взаимодействие с БД только через DAL. Никаких исключений. На этот уровень можно вынести только контроль транзакций. Классы BL строго stateless, никакого сохранения состояния между вызовами.

DAL — Data Access. Никакой логики, кроме конструирования объектов из рекордсетов и наоборот. Весь маппинг делается здесь.

Методы BL и DAL вообще можно сделать статическими, но в этом случае мы теряем некоторые возможности по повторному использованию т.к. лишаемся виртуальных вызовов. Классы BL могут использовать DAL либо как агрегированные объекты, либо, опять же, как статические методы, либо создавать их всякий раз при необходимости. Ещё один (не очень кошерный) способ — использование наследования, т.е. когда класс бизнес логики наследуется от соответствующего ему DAL класса. Такая схема неплохо работает, когда имеется много pass-through методов.