Как обычно структурируется BLL (CRUD и бизнес-объект)?

Question

Это в связи с этим вопрос:

What to put in Business Logic Layer?

С ответами на этот вопрос (еще не выбрали ответ, как там могут быть и другие, желающие комментировать, чтобы сделать его более понятным для меня), я мы пришли к выводу, что BLL будет включать CRUD и будет обращаться к DAL по мере необходимости.

Моя главная проблема теперь в том, как выглядит мой BLL? Скажем, например, объект Order. Для CRUD, я вижу некоторые реализации, что имеет OrderService, которая является частью УСК, как это:

public class OrderService 
{ 
    public int CreateOrder(Order order) 
    { 
     ... 
    } 

    public int UpdateOrder(Order order) 
    { 
     ... 
    } 

    //... other code for CRUD 
} 

Дело с этим в стороне от бизнес-объектов, я бизнес-объектов, связанных с услугами в УСК?

В то время как на некоторых других они делают что-то вроде этого:

public class Order 
{ 
    public int ID { get; set; } 
    public decimal Amount { get; set; } 
    //... etc. 

    public int Create() 
    { 
     ... 
    } 

    public int Update() 
    { 
     ... 
    } 
} 

Но это, кажется, как-то неправильно (объединение операций CRUD и свойства).

Как обычно структурируется BLL (CRUD и бизнес-объект)?

Кроме того, поскольку данные, как правило, поступают из ввода пользовательского интерфейса, а затем заполняются объектом Business, как я могу проверить данные? Например, у меня есть свойство Total для заказа и List, Total должно равняться общему количеству OrderItem. Когда я говорю CreateOrder, как бы я вызвал проверку? Я всегда думал, что валидация должна быть сделана внутри реальных агентов по созданию свойств. Как я буду ссылаться на это во время CRUD? Должен ли я реализовать метод Validate в бизнес-объекте?

Любые материалы об этом были бы очень желанными.

Answer 1

Основываясь на своем опыте, я предпочел бы использовать первый. Если есть более сложная бизнес-логика, то определенно. Обычно у меня есть следующие слои в применении в комплекс:

• View. Страницы бритвы
• Модель. Модели Data Transfer Objects, которые представляют собой что-то , а не что-то из базы данных.
• Контроллер. Контроллеры могут быть light-weight, только соединяющие презентацию и бизнес-логику.
• Бизнес-логика. Я предпочитаю помещать BL в отдельную библиотеку (BLL). Бизнес-логика взаимодействует с контроллерами MVC (через DTO) и уровнем данных.
• Уровень данных. Манипулирование через EF.

DTO могут быть созданы из нескольких объектов DB; они также могут быть частичным представлением, если вы хотите скрыть некоторые детали. Подробнее in this question. DTO также являются хорошим способом заставить себя предотвратить unintended updates - или см. here.

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

И позвольте мне еще раз подчеркнуть: не используйте пушку, чтобы стрелять воробьи ... Простые задачи требуют простых решений.

ADD-ON

можно сопоставить объекты БД в DTO лиц выражениями селекторных. Пример: here, я добавил еще один пример, предположив, что в базе данных есть таблица Kitten.

Class KittenDto { 
    public static Expression<Func<Db.Kitten, KittenDto>> = (kitten) => return new KittenDto() { 
     Id = Id, 
     Name = Name, 
     CustomDataNotInDb = 42 
    }; 
    public int Id; 
    public string Name; 
    public int CustomDataNotInDb; 
} 

Затем вы можете использовать:

var kittenDto = context.Kittens 
    .Single(k => k.Id == givenId) 
    .Select(KittenDto.Selector); 

Берегись, если Selector не является Expression<> то оно выполняется локально. Если это Expression, то он преобразуется в запрос, а БД выполняет остальную часть работы. Результатом работы БД будет объект KittenDto (точнее: он будет иметь только запрашиваемые свойства, не более того).

Также имейте в виду, что писать сложные выражения может быть сложно - или это было, когда я использовал его в последний раз вокруг .NET 4.5. Например, вызовы функций не могут выполняться в запросах БД, только некоторые очень распространенные (например, некоторые строковые операции).