Шаблон хранилища и/или/vs уровень бизнес-логики

У меня проблема, я хочу знать ваше мнение.

Я пытаюсь использовать шаблон репозитория. У меня есть объект репозитория, который загружает данные в POCO. Я также создал слой бизнес-логики, который добавляет немного функциональности, но в основном обертывает POCO. Поэтому в конце я имею BLL, который загружает DAO с использованием репозитория.

Я не очень доволен этим решением. У меня три слоя, но я чувствую, что BLL не обеспечивает достаточную функциональность, чтобы держать его там. С другой стороны, я не хочу ставить свою логику на уровне репозитория или на уровне доступа к данным?

Итак, мой вопрос в том, где я должен поставить логику для приложения? Какое решение вы используете (DAO + repo или DAO + BLL + rep или любой другой)?

Ответ 1

Существует два основных способа думать о бизнес-правилах при разработке вашего домена.

1.) Объекты домена являются базовыми POCO/DTO. И вы передаете их в службы домена. Эти службы могут быть такими же простыми, как и другой класс, или они действительно могут быть фактическими службами, сидящими на другом сервере.

var user = repository.Find(x => x.UserName == userName);
if (userLogonService.IsValidUser(user, password)) {
   userLogonService.UpdateUserAsLoggedOn(user);
}
repository.SaveChanges();

2.) Объекты домена содержат свою собственную логику работы. Это ближе к тому, за чем последуют многие шаблоны MVC. И поскольку вы спросили, это модель, которую я предпочитаю.

var user = repository.Find(x => x.UserName == userName);
if (user.CheckPassword(password)) {
    user.LogOnNow();
}
repository.SaveChanges();

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

РЕДАКТИРОВАТЬ # 1: Ответ на John Kraft

Oven.Bake(myPizza) vs. myPizza.Bake()

Я в основном согласен. У вас есть одно обслуживание в духовке, или у вас есть десятки доступных печей, хранящихся в репозитории печи, где печь - это еще один объект домена? В № 2 печь является частью домена. Как я обычно делаю моделирование домена, большинство существительных являются сущностями домена, если вы на 100% не уверены, что есть что-то одно.

Но что-то случается с пиццей, когда она выпекается.

interface ICanBeBaked {
    int BakeMinutes { get; }
    int BakeTemp { get; }
    void Bake();
}
class Pizza : ICanBeBaked {
    int BakeMinutes { get { return 15; } }
    int BakeTemp { get { return 425; } }
    void Bake() {
        // melt cheese!
        this.isBaked = true;
    }
}
class Oven {
    void Bake(ICanBeBaked thingToBake) {
        // set the temp, reserve this oven for the duration, etc.
        thingToBake.Bake();
    }
}

Ответ 2

Мой "DAL" (больше домашней ORM, которая является другой темой) - это действительно пара слоев; одна абстракция, которая предоставляет репозиторий и некоторую активную поддержку шаблонов записей, а ниже - фактический код доступа к данным.

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

Это довольно стандартное расслоение. Вы не говорите, почему вы недовольны своим текущим стеком, но имейте в виду, что основной причиной для этого является разделение обязанностей. Вы также можете взглянуть на концепции Domain Driven Design; он предоставляет массу пищи для размышлений о организации кода вокруг бизнес-политики и практики, а не конкретно в вопросах программного обеспечения. Это очень полезный аналитический инструмент для использования в вашем ящике инструментов.