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

_>Если обобщить, то бизнес сущности должны максимально быть похоже на свой источник данных.

Да. Упрощается мапинг.

_>Никаким образом не должны пересекаться с DAL, не должны знать о своём происхождении.

Пересекаться они будут, но с другой стороны. DAL о них будет знать всё.

_>Бизнес сущности должны быть самодостаточными, т.е недопустимо чтобы за какой-то порцией данных было обращение к DAL, интересно а как-же с lozy load?

Это не так. Самодостаточность необязательное условие. Этак можно всю базу через одну сущность вытянуть. К тому же, если я вывожу списко из 1000 ордеров, то одновременное поднятие деталей без необходимости только нагрузит сервера и трафик. Сущности надо поднимать по мере необходимости. У меня обычно получается набор методов типа GetOrderByID, GetOrderDetailsByID, GetOrderListByCustomer и т.п. Первого метода может и не быть, но если есть, то он возвращает только одну записть из таблицы Order, второй метод поднимает Order и все его детали, Items, Addresses и т.п., третий деталей тоже не возвращает, только главные записи. Если мне нужны детали для конкретного ордера, то я вызову потом GetOrderDetailsByID. Но всё это, конечно же, зависит от задачи. Lazy loading я не использую. Красивая идея, но таит в себе множество подвохов. К тому же LL применяется в основном в системах построенных в стиле объектной модели (точнее в стиле пьяной обезъяны, по другому не назовёшь), я же здесь пропогандирую совершенно другой стиль

_>В моём случае получается, что функцию расчёта надо вынести из БО Company и перенести её в CompanyManager, который имеет отношение бизнес логике.

Точно.

_>Правильно ли расматривать БО, как плоский объект, который должен иметь самую примитивную логику.

Самую примитивную да. Что такое 'плоский' я плохо себе представляю.

_>Каждый БО должен иметь объект БЛ который оперирует им (CompanyManager <---> Company)

Интересный вопрос. Иногда это понимается именно так: один Manager — один БО. Тогда лучше думать о таких объектах как о сервисах: один Service — одна подсистема. Как правило такая подсистема обслуживает одну или несколько высокоуровневых сущностей и кучу вспомогательных. Например, OrderingService, всё о заказах.

_>Если у меня запрос состоит из нескольких таблиц, то как надо загружать БО? На каждую таблицу по БО или БО общий на запрос?

Что имеется ввиду, несколько таблиц в одном запросе (JOIN) или несколько запросов за один раз?

В случае с заказами (GetOrderDetailsByID) можно было бы написать такой спрок:

CREATE PROCEDURE GetOrderDetailsByID
    @OrderID int
AS

    SELECT
        Все_поля
    FROM
        Order
    WHERE
        OrderID = @OrderID
    
    SELECT
        Все_поля
    FROM
        OrderItem
    WHERE
        OrderID = @OrderID

GO

Далее DAL при использовании RFD получается примерно такой:

public Order GetOrderDetailsByID(int id)
{
    using (DbManager   db = new DbManager())
    using (IDataReader dr = db
        .SetSpCommand("GetOrderDetailsByID", id)
        .ExecuteReader())
    {
        if (rd.Next())
        {
            Order order = (Order)Map.ToObject(rd, typeof(Order));
            
            rd.NextResult();
            Map.ToList(order.Items, typeof(OrderItem));
            
            return order;
        }
    }
}

BL метод вырождается в pass-through.

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

_>У меня есть объект DataManager, который абстрагирует работу с базой, правильно ли его создавать в етом слое и передабать объекту ДАЛ, или объект ДАЛ должен сам его создавать.

В случае с транзакциями его необходимо создавать в BL и передавать как параметер в DAL.