Шаблон репозитория и / или / против уровня бизнес-логики

Question

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

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

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

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

Answer 1

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

1.) Доменные сущности - это базовые POCO / DTO s.И вы передаете их доменным службам.Эти сервисы могут быть такими же простыми, как другой класс, или они действительно могут быть реальными сервисами, расположенными на другом сервере.

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: Ответ Джону Крафту

Oven.Bake (myPizza) против 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();
    }
}

Answer 2

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

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

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