Зависимости лука в архитектуре на одном уровне: инфраструктура и веб-коммуникация

Question

Я разрабатываю приложение ASP.NET MVC, используя Onion Architecture , описанную Джеффри Палермо.

Это проект ASP.NET MVC 2.0, где я требую строгой типизации всех представлений с использованием выделенных моделей представлений - мы не будем передавать доменные модели нашим представлениям. Для перевода мы используем AutoMapper - AutoMapper изолирован в инфраструктуре, Web не знает и не заботится об использовании AutoMapper.

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

Чтобы обеспечить фактическую реализацию интерфейсов IViewModelMapping, я создал пространство имен ObjectMapping в проекте инфраструктуры, который изолирует фактическую реализацию сопоставления от внутренней структуры лука. Для этого потребуется, чтобы инфраструктура зависела от ОБА Ядра И Сети.

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

Альтернативным вариантом было бы перемещение интерфейсов IViewMapper в Core, но это было бы невозможно, поскольку у Core нет доступа к классам ViewModel. Я также мог бы переместить модели представления в Core, но я чувствую, что они не будут там принадлежать, так как они относятся к слою пользовательского интерфейса.

Предложенная архитектура выглядит следующим образом - обратите внимание, что инфраструктура зависит от Core AND Web. Сеть остается изолированной и имеет доступ только к основной бизнес-логике.

http://www.matthidinger.com/images/onion-arch.png

Answer 1

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

Я бы подумал, что вместо IViewModelMapping создайте IMapper с помощью метода Map (). Затем интерфейс может иметь реализации, которые могут иметь отношение к отображению модели представления или, может быть, просто к обычному отображению. В любом случае, этот интерфейс может быть в Core, поскольку он не связан семантически с каким-либо типом модели.

Отличная графика. Я надеюсь, что ответил на вопрос вашего вопроса. Общая философия Onion Architecture заключается в том, чтобы держать свою бизнес-логику и модель в середине (ядро) приложения и расширять зависимости как можно дальше.

Answer 2

Ваш уровень Web / UI может зависеть от уровня инфраструктуры. Но не очень хорошо иметь зависимость Web от слоя Infrastructure. Архитектура лука говорит, что вы должны вытолкнуть свои зависимости как можно дальше наружу.

Вы можете создать папку "\ Builder" в пользовательском интерфейсе. Добавьте в него один интерфейсный файл, например. IBuilder или IMapper и объявите в нем метод типа ConvertToViewModel или CreateMapping. как хочешь.

* Builder ** IBuilder.cs - объявить метод здесь. ** Builder.cs - - Реализуйте здесь метод, определите отображение между ViewModel и его соответствующей DomainModel (ссылка из основного уровня) и верните соответствующий ViewModel здесь.

Answer 3

Попробуйте переместить Отображение объектов в Веб слой.