Зависимости архитектуры Onion в том же слое:Инфраструктура и веб-коммуникация
-
22-09-2019 - |
Вопрос
Я разрабатываю приложение ASP.NET MVC с использованием Луковая Архитектура описан Джеффри Палермо.
Это проект ASP.NET MVC 2.0, где я требую, чтобы все представления были строго типизированы с использованием выделенных моделей представлений - мы не будем передавать модели предметной области в наши представления.Мы используем AutoMapper для выполнения перевода - AutoMapper изолирован в инфраструктуре, Веб не знает и не заботится о том, что AutoMapper используется.
В настоящее время я определяю интерфейсы IViewModelMapping в веб-проекте - просто потому, что эта служба будет использоваться контроллерами и у нее есть прямой доступ к своим собственным моделям представления.Таким образом, интерфейс может получить доступ как к Моделям предметной области (в Core), так и к Моделям представления (в Web).
Чтобы обеспечить фактическую реализацию интерфейсов IViewModelMapping, я создал пространство имен ObjectMapping в проекте инфраструктуры, которое изолирует фактическую реализацию сопоставления от внутренней структуры onion.При этом потребуется, чтобы Инфраструктура зависела КАК от Ядра, ТАК И от Интернета.
Мой вопрос заключается в следующем:поскольку оба этих проекта технически находятся на окраине onion (в одном и том же слое) - разрешено ли одному проекту иметь зависимость от другого проекта в этом слое?Кто-нибудь замечает какие-либо потенциальные подводные камни в этом дизайне?
Альтернативным вариантом было бы перемещение интерфейсов IViewMapper в Core, но это было бы невозможно, поскольку Core не имеет доступа к классам ViewModel.Я мог бы также переместить модели просмотра в Ядро, но я чувствую, что им там не место, поскольку они специфичны для уровня пользовательского интерфейса.
Предлагаемая архитектура выглядит следующим образом - обратите внимание, что Инфраструктура зависит от Ядра И Интернета.Веб остается изолированным и имеет доступ только к основной бизнес-логике.
Решение
Вы правы в том, что не хотите, чтобы инфраструктура зависела от пользовательского интерфейса (Интернет), но иногда я нарушаю это правило.
Я бы подумал вместо IViewModelMapping создать IMapper с помощью метода Map().Затем интерфейс может иметь реализации, которые могут иметь отношение к сопоставлению модели представления или, возможно, просто к обычному сопоставлению.В любом случае этот интерфейс может находиться в Core, поскольку он семантически не связан с каким-либо типом модели.
Отличная графика.Надеюсь, я ответил на суть вашего вопроса.Общая философия луковой архитектуры заключается в том, чтобы держать вашу бизнес-логику и модель в середине (ядре) вашего приложения и выдвигать ваши зависимости как можно дальше наружу.
Другие советы
Попробуйте двигаться Сопоставление объектов в Интернет слой.
Ваш уровень веб-интерфейса может зависеть от уровня инфраструктуры.Но это не очень хороший дизайн - иметь зависимость Интернета от уровня инфраструктуры.Луковая архитектура гласит, что расширяйте свои зависимости как можно дальше вовне.
Вы можете создать папку "\Builder" в пользовательском интерфейсе.Добавьте в него один файл интерфейса, например..IBuilder или IMapper и объявите в нем метод, подобный ConvertToViewModel или CreateMapping.все, что тебе заблагорассудится.
*Builder ** IBuilder.cs -объявляет метод здесь.**Builder.cs -- - Реализуйте метод здесь, определите сопоставление между ViewModel и соответствующей ему DomainModel (ссылка с базового уровня) и верните соответствующую ViewModel здесь.