n-слойный дизайн бизнес / сервисного уровня

Question

Я пытаюсь пересмотреть нашу n-слойную архитектуру и хотел бы получить некоторые предложения, основанные на вашем опыте.Вот наш типичный .NET n-слойный (иногда n-уровневый) дизайн.

Project.UI
Project.Services
Project.Business
Project.Model
Project.DataAccess

DataAccess обычно состоит из Entity Framework 4 и Repository классов.Я пытаюсь следовать концепции Aggregate Root, чтобы избежать использования хранилища для таблиц, что легче сказать, чем сделать по моему опыту.Я склонен иметь ~ 70% совпадение между хранилищами и таблицами.

Модель обычно состоит из моих Entity Framework 4 сущностей, я успешно использую сущности EF Self-Tracking.

Бизнес - это то, с чем я больше всего борюсь.У меня обычно есть Manager класс для каждого Repository.Этот класс будет содержать методы, такие как .Add (), которые будут выполнять проверку бизнеса перед пересылкой в ​​репозиторий.Add ().

Службы, обычно я реализую это только в том случае, если на самом деле я ищу создание веб-службырешение на основеЭтот уровень будет отвечать за маршалинг запросов / ответов между DTO и организациями.И самое главное предоставить более coarse grained интерфейс.Например, TradingService.SubmitTrade (), который на самом деле является facade для бизнес-операции, которая может включать AccountManager.ValidateCash (), OrderManager.SubmitOrder () и т. Д.

Касается
Мой бизнес-уровень очень ориентирован на сущности, на самом деле это всего лишь связующее звено между сущностями и хранилищем с промежуточной проверкой.Я видел много проектов, где Service Layer - это то, что содержит ссылку на репозитории (по сути, пропуская «бизнес-уровень»).По сути, он служит той же цели, что и мой бизнес-уровень, он выполняет проверку, однако его ответственность (и наименование) - это более высокоуровневая, более грубая бизнес-операция.Используя приведенный выше пример, TradingService.submitTrade () не будет делегировать какие-либо классы бизнес-менеджера, он сам запросит необходимые репозитории, выполнит всю проверку и т. Д.

Мне нравится мой дизайн в том смысле, что я могу использовать его повторнометод бизнес-уровня в нескольких вызовах сервисов, однако я ненавижу тот факт, что для каждого репозитория у меня есть соответствующий менеджер бизнес-уровня, создающий тонны дополнительной работы.Может быть, решение - это другой тип группировки на уровне бизнес-уровня?Например, объедините отдельные классы Manager, такие как PhoneManager и EmailManager (заметьте, у меня есть сущности Phone и сущности электронной почты), в логический класс Manager, такой как ContactsManager (заметьте, у меня нет типа сущности «Контакт»).С такими методами, как ContactManager.GetPhones () и ContactManager.GetEmail () и т. Д.

Мне кажется, больше всего на свете мне интересно, как другие организуют и делегируют обязанности, имеют ли они сервисный уровень, бизнес-уровень, обаи т. д. Что содержит ссылку на контекст ORM и т. д.

Answer 1

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

Например, используя Контакты, у меня точно не будет PhoneManager или EmailManager. «ContactsManager» - это более полезная для меня группа, которая выполняет почти то же самое, только с гораздо меньшим количеством менеджеров. С деловой точки зрения, телефонные номера и электронные письма - это всего лишь маленькие кусочки Контакта. То, что у них есть собственные таблицы и сущности, не означает, что им нужен собственный менеджер. Это не значит, что вы не можете использовать их повторно. Если вам нужно работать с адресами электронной почты в нескольких местах, ContactsManager может использовать соответствующие методы.

В нашей среде мы обычно имеем уровень базы данных / сущности, а затем бизнес-уровень, который располагается на сервере и обрабатывает бизнес-правила и бизнес-логику. Этот бизнес-уровень предоставляется клиенту как услуга через WCF (или, по крайней мере, материал, относящийся к клиентам).

Похоже, вы уже знаете, что хотите сделать, поэтому я бы посоветовал немного поработать над ним и посмотреть, как он работает для вас. :)