IT>Бизнес сущности. Классы описывающие предметную область: Company, CompanyNegativeInfo и т.п. Желательно, что бы эти классы совпадали со структурой таблиц БД. В этом случае маппинг можно сдлать абсолютно примитивным, что существенно упростит DAL. В зависимости от общей архитектуры бизнес сущности могут быть вынесены в отдельный проект.
Если обобщить, то бизнес сущности должны максимально быть похоже на свой источник данных.
Никаким образом не должны пересекаться с DAL, не должны знать о своём происхождении.
Бизнес сущности должны быть самодостаточными, т.е недопустимо чтобы за какой-то порцией данных было обращение к DAL, интересно а как-же с lozy load?
В моём случае получается, что функцию расчёта надо вынести из БО Company и перенести её в CompanyManager, который имеет отношение бизнес логике.
Правильно ли расматривать БО, как плоский объект, который должен иметь самую примитивную логику.
Каждый БО должен иметь объект БЛ который оперирует им (CompanyManager <---> Company)
Если у меня запрос состоит из нескольких таблиц, то как надо загружать БО? На каждую таблицу по БО или БО общий на запрос?
IT>Бизнес логика. Сервисы или менеджеры (как больше нравится). Всё взаимодействие с БД только через DAL. Никаких исключений. На этот уровень можно вынести только контроль транзакций. Классы BL строго stateless, никакого сохранения состояния между вызовами.
У меня есть объект DataManager, который абстрагирует работу с базой, правильно ли его создавать в етом слое и передабать объекту ДАЛ, или объект ДАЛ должен сам его создавать.
IT>DAL — Data Access. Никакой логики, кроме конструирования объектов из рекордсетов и наоборот. Весь маппинг делается здесь.
IT>Методы BL и DAL вообще можно сделать статическими, но в этом случае мы теряем некоторые возможности по повторному использованию т.к. лишаемся виртуальных вызовов. Классы BL могут использовать DAL либо как агрегированные объекты, либо, опять же, как статические методы, либо создавать их всякий раз при необходимости. Ещё один (не очень кошерный) способ — использование наследования, т.е. когда класс бизнес логики наследуется от соответствующего ему DAL класса. Такая схема неплохо работает, когда имеется много pass-through методов.
