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

Question

У меня есть хранилище ( CustomerRepository ), которое извлекает данные из уровня данных. Большая часть бизнес-логики находится в классе сущностей ( Customer ), который репозиторий либо принимает, либо возвращает.

Однако куда вы помещаете глобальную бизнес-логику сущности (которая применяется ко всем клиентам)?

Например, я не хочу возвращать всех клиентов определенным пользователям. Я не хочу помещать эту логику в хранилище.

Answer 1

Я согласен с Робертом Мунтяну.

По сути, вы сворачиваете свою бизнес-логику, которая не присуща вашей модели, в средний уровень. Средний уровень - это бизнес-уровень / бизнес-объекты / уровень бизнес-логики / и т. Д., Но он просто называется уровнем обслуживания. Это не обязательно должен быть веб-сервис, он широко использует термин «сервис» в том смысле, что он объединяет функциональность определенной прикладной области.

У вас будет класс CustomerService, содержащий ссылку на репозиторий. Ваш уровень представления будет ссылаться на класс уровня обслуживания.

Существует дополнительное отличие, которое можно сделать, исходя из вашего имени, которое вы используете .net и, возможно, используете LINQ to SQL в качестве хранилища, как описано в NerdDinner.

Репозиторий обычно возвращает IQueryable на сервисный уровень, что позволяет цепочке сервисного уровня объединять несколько запросов для создания разных наборов результатов. Служба затем оценивает выражение, используя ToList или другой подобный метод, и возвращает его на уровень представления.

Answer 2

Оберните это позади службы.

Answer 3

Поместите его в другой репозиторий (BusinessRuleRepository) и сделайте так, чтобы CustomerRepository использовал его.

ИЛИ

Если бизнес-логика ограничивает только результаты, которые видит пользователь, вы можете использовать шаблон Фасад с фабрикой. В этом случае у вас будет ICustomerRepository, который обрабатывает ваши CustomerRepository и LimitedCustomerRepository (который может инкапсулировать CustomerRepository), и CustomerRepositoryFactory, который возвращает соответствующий ICustomerRepository для пользователя.

Answer 4

Я думаю, что разделение этих типов функций на сервисный уровень - это путь.

Недавно я создал систему для комплексного прогнозирования со многими объектами, используя исторические данные. Помещение всех битов доступа к данным в хранилище для каждого объекта. Сложную логику прогнозирования я сохранил на уровне сервиса и передал объекты хранилища по мере необходимости.

Дополнительным бонусом стало то, что у меня был простой способ показать всю логику прогнозирования внешним системам, просто создав слой веб-API.