Около года назад я установил решение, состоящее из уровня представления ASP.Net MVC 3 (сейчас), уровня приложения, уровня домена и уровня инфраструктуры (пересекающихся материалов и данных). Я решил сохранить модель предметной области в отдельном проекте от логики предметной области и использовать расслабленный подход к уровню представления, передав сущности предметной области вместо DTO, поскольку сейчас у нас действительно только 1 интерфейс.
Вскоре мы собираемся обслуживать распределенный уровень в дополнение к нашему основному веб-сайту, и я буду использовать там DTO, но я также рассматриваю возможность использования DTO на основном веб-сайте. Мне также интересно, стоит ли мне потрудиться, чтобы разбить код фреймворка на уровне домена (IRepository, IUnitOfWork, супертипы объектов Entity / Value и т. Д.). Итак, позвольте мне перечислить вопросы, по которым мне нужна обратная связь:
1) Я очень старался не иметь анемичной модели предметной области, а также следил за поведением, которое было характерно для проблем презентации. Большая часть необходимых бизнес-вычислений выполняется на объектах домена. Допустимо ли для уровня представления вызывать это поведение напрямую или вместо этого он должен вызывать службу приложения, которая затем вызывает объекты домена? Это наводит на мысль, что нет причин, чтобы уровень представления знал об объектах домена и вместо этого мог использовать DTO. В качестве альтернативы я мог бы заставить DTO раскрыть это поведение, но тогда я чувствую, что граблю объекты домена. Итак, я предполагаю, что это 3 варианта (богатые объекты домена, вызываемые напрямую, уровень обслуживания или dto с поведением), что лучше всего?
2) Прямо сейчас у меня есть проект предметной области, который содержит сервисы, спецификации и логику предметной области и управляется прикладным уровнем и отдельным проектом для модели предметной области (используется уровнем представления и уровнем приложения). У меня также есть интерфейсы фреймворка для общего репозитория и шаблона единицы работы. Должен ли я разбить фреймворк на отдельный проект, а остальное объединить в один?
3) Я хочу реорганизовать свой уровень домена в агрегаты, прямо сейчас вся модель домена организована по модулям, в основном все типы для каждого модуля находятся в одном пространстве имен. Было бы лучше организовать сущности, объекты значений, услуги и прочее по агрегатам?
4) Следует ли мне использовать шаблон раздельного интерфейса для служб инфраструктуры, которые в основном являются вспомогательными библиотеками .NET Framework? Например, объекты конфигурации или средства проверки? Какая в этом польза?
5) Наконец, я видел не так много примеров, в которых использовались интерфейсы для сущностей предметной области. Почти каждый объект, который у меня есть, я предпочитаю передавать по интерфейсам по причинам зависимости, и это значительно упрощает тестирование. Допустимо ли использовать интерфейсы вместо бетона? Я должен упомянуть, что мы используем EF 4.3.1 (скоро для обновления до последней версии), и я, кажется, помню, что у EF была проблема с использованием интерфейсов или что-то в этом роде. Должен ли я показывать интерфейсы вместо сущностей домена?
Заранее большое спасибо.
Структура проекта:
Presentation.Web
| |
| Application
| | |
Domain.Model - Domain
(Infrastructure.Data, Infrastructure.Core, Infrastructure.Security)
Объяснение: Presentation.Web (веб-проект MVC3)
Приложение - уровень обслуживания, который управляет уровнем домена и отвечает на запросы уровня представления (получите это обновление). Это организовано по модулям, например, если бы у меня был клиентский модуль, у меня был бы Application.Customer, и в нем были бы все службы приложения.
Домен - содержит доменные службы, спецификации, вычисления и другую логику домена, которая не отображается как поведение на объектах домена. Например, расчет, в котором задействованы несколько объектов домена, представленных как служба домена для вызова прикладного уровня. - Также содержит код платформы для структуры спецификации и основные интерфейсы для универсального репозитория и шаблона единицы работы.
Domain.Model - содержит сущности и перечисления домена. Организовано по модулю. Например, если у меня может быть модуль клиента, у которого есть сущность клиента, сущность customerorder и т. Д. Это отделено от проекта домена, так что объекты могут использоваться на уровне приложения и презентации.
Infrastructure.Security - Инфраструктура безопасности для аутентификации и авторизации.
Infrastructure.Core - сквозной материал, используемый на нескольких уровнях (валидаторы, ведение журнала, конфигурация, расширения, IoC, электронная почта и т. Д.). Большинство проектов зависят от интерфейсов в этом проекте (кроме domain.model) для служб инфраструктуры.
Infrastructure.Data - реализации репозитория через LINQ и EF 4.3.1, слой сопоставления, реализация единицы работы. Интерфейсы находятся в проекте домена (разделенный шаблон интерфейсов)
