Мнение о архитектуре ASP.NET MVC Onion

Ответ 1

Ничего себе, здесь многое сказать!; -)

Прежде всего, давайте поговорим об общей архитектуре.

То, что я вижу здесь, это то, что на самом деле это не лунная архитектура. Вы забыли внешний слой, слой "Разрешение зависимостей". В архитектуре Onion, вплоть до этого уровня, для подключения основных интерфейсов к реализации инфраструктуры (где должен находиться ваш проект Persistence).

Вот краткое описание того, что вы должны найти в приложении "Лук". Что касается уровня Core, все это уникально для бизнеса: модель домена, бизнес-процессы... Этот уровень определяет все потребности в технической реализации в качестве интерфейсов (например: интерфейсы репозиториев, интерфейсы ведения журнала, интерфейсы сеансов...). Уровень ядра не может ссылаться на любые внешние библиотеки и не имеет специального кода для конкретной технологии. Второй уровень - это уровень инфраструктуры. Этот уровень обеспечивает реализацию для не-бизнес-интерфейсов Core. Здесь вы вызываете свою БД, свои веб-службы... Вы можете ссылаться на любые внешние библиотеки, которые вам нужны для обеспечения реализаций, развертывать столько пакетов самородок, сколько хотите:-). Третий уровень - это ваш пользовательский интерфейс, ну, вы знаете, что добавить туда;-) И последний уровень, его разрешение зависимостей, о котором я говорил выше.

Направление зависимости между слоями относится к центру.

Вот как это могло бы выглядеть:

Теперь возникает вопрос: как подогнать то, что вы уже закодировали в архитектуре лука.

Ядро: содержит модель домена

Да, это подходящее место!

Стойкость - интерфейс и реализации репозитория

Ну, вам нужно разделить интерфейсы с реализациями. Интерфейсы необходимо перенести в Core, а реализации необходимо перенести в папку Infrastructure (вы можете назвать этот проект Persistence).

BusinessServices - бизнес-уровень вокруг репозитория. Все бизнес-логика должна быть здесь

Это нужно перенести в Core, но здесь вы не должны использовать реализации репозиториев, просто манипулируйте интерфейсами!

Web (или любой другой пользовательский интерфейс). В этом конкретном случае это MVC Приложение

cool: -)

Вам нужно добавить проект "Bootstrapper", просто посмотрите здесь, чтобы узнать, как продолжить.

О ваших смешанных чувствах:

Я не буду обсуждать необходимость наличия репозиториев или нет, вы найдете много ответов на stackoverflow.

В моем проекте ViewModel у меня есть папка под названием "Builder". Его до моих Строителей обсуждать с моими интерфейсами бизнес-сервисов для получения данных. Строитель получит списки объектов Core.Domain и отобразит их в правую ViewModel.

О том, что вам не нравится:

В классической архитектуре лука на ядре ссылаются только следующие слой.

Ложь!:-) Каждому слою требуется, чтобы Core имел доступ ко всем интерфейсам, определенным там.

DbContext реализован в проекте .Core, поскольку он созданный платформой Entity Framework, в том же месте, где .edmx это

Еще раз, это не проблема, как только ее очень легко редактировать шаблон T4, связанный с вашим EDMX. Вам просто нужно изменить путь к сгенерированным файлам, и вы можете иметь EDMX на уровне инфраструктуры и POCOs в вашем проекте Core.Domain.

Надеюсь, это поможет!

Ответ 2

Я ввожу свои службы в свои контроллеры. Службы возвращают DTO, которые находятся в Core. Модель у вас хорошо выглядит, я не использую шаблон репозитория, но многие люди делают это. Мне сложно работать с EF в этом типе архитектуры, поэтому я решил использовать Nhibernate.

Возможный ответ на ваш последний вопрос.

• CORE
• DOMAIN
• DI
• ИНФРАСТРУКТУРА
• ПРЕЗЕНТАЦИЯ
• УСЛУГИ

Ответ 3

По-моему:

• "В классической архитектуре лука на ядре ссылается только следующий слой". Это не так, Core должен быть ссылкой любым слоем... помните, что Направление зависимости между слоями относится к центру (Core).

"слои выше могут использовать любой слой под ними". Джеффри Палермо http://jeffreypalermo.com/blog/the-onion-architecture-part-3/

• О вашем EF, он находится в неправильном месте.... он должен быть в слое Infrastructure не на уровне Core. И используйте POCO Generator для создания сущностей (классы POCO) в Core/Model. Или используйте Auto-mapper, чтобы вы могли сопоставить Core Model (Бизнес-объекты) с Entity Model (EF Entities)

В другой руке я создал простое приложение с использованием Onion Architecture, чтобы показать зависимости между уровнями и способы их реализации. http://www.jaider.net/posts/935-onion-architecture-in-action-get-started/

Ответ 4

То, что вы сделали, выглядит довольно хорошо и в основном является одной из двух стандартных архитектур, которые я вижу много.

Смешанные чувства о:

Хорошо, у нас есть реалистичная реализация репозитория, но как часто у вас действительно разные реализации одного и того же интерфейса персистентности?

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

Я не уверен, что пользовательский интерфейс должен только взаимодействовать с бизнес-слоем через модели просмотра или использовать модели домена для передачи данных, как и сейчас. Для отображения я использую модели просмотра, но для передачи данных я использую модели домена. Неправильно?

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

Что мне не нравится:

Проект Core теперь ссылается на каждый другой проект - потому что я хочу/должен получить доступ к моделям Домен. В классической архитектуре лука на ядре ссылается только следующий слой.

Как говорили другие, это вполне нормально. Обычно все заканчивается тем, что имеет зависимость от Домена.

DbContext реализуется в проекте .Core, потому что он генерируется платформой Entity Framework в том же месте, где находится .edmx. Я действительно хочу использовать .EDMX для визуального моделирования модели, но я чувствую, что DbContext относится к уровню Persistence, где-то в реализации репозитория конкретной базы данных.

Я думаю, что это является следствием Entity Framework. Если вы использовали его в режиме "Первый код", вы фактически можете - и обычно - иметь контекст и репозиторий на уровне Persistance с Доменом (представленным как классы POCO) в том, что вы назвали Core.

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

Как я коснулся выше, я не стал бы беспокоиться о необходимости замены вещей, кроме как для автоматических модульных тестов. Если не существует конкретного требования, о котором вы знаете, это очень вероятно.

Удачи!