DAL -> BLL <- GUI + составной корень. Как настроить DI-привязки?

Question

Я сделал трехслойное приложение с ссылками, действующими, как описано в этом ответе :

DAL with Repositories -> BLL with services and IRepository <- Asp.net mvc-app

Чтобы запустить его с внедрением зависимости, я вижу несколько вариантов:* 1. Добавьте ссылку на DAL из веб-приложения, чтобы иметь возможность настроить привязки при запуске приложения.
2. Используйте контейнер с xml-конфигурацией
(3. Используйте отражение, чтобы загрузить dal-сборку инайти типы)

Вариант 1. прост и также позволяет копировать DAL.dll в bin, но затем я неожиданно возвращаю ссылку, от которой я так усердно избавлялся.Теперь к репозиториям можно получить доступ напрямую.Варианты 2 и 3 кажутся излишне сложными.

Нет другого пути?

Answer 1

Разделите приложение ASP.NET MVC на две части:

• Одна часть - это ваше исходное приложение ASP.NET MVC, но без какой-либо логики.Просто сохраните Composition Root и ваши представления (.aspx и т. Д.) В этом проекте.Поскольку это корень композиции, у вас могут быть ссылки на все другие ваши проекты.Однако, поскольку вся логика была бы извлечена, теперь это Humble Object , поэтому все ссылки на этом уровне можно использовать.
• Извлечение всей логики (контроллеры и т. Д.)) в проект Application Model , который будет просто обычным библиотечным проектом (.dll), который ссылается на двоичные файлы ASP.NET MVC.Этот проект должен будет ссылаться на BLL, чтобы добраться до интерфейсов, но это нормально.Тем не менее, и модель приложения, и BLL эффективно защищены от DAL.

Получившееся наложение будет выглядеть следующим образом:

• Приложение ASP.NET MVC
• Модель приложения
• BLL
• DAL

Answer 2

Ответ Марка Симанна дал мне идею для этого варианта:

DAL with Repositories -> BLL with services and IRepository <- Asp.net mvc-app
^------------------------^--------- Composition Root <-------´

Это должно проиллюстрировать, что вместо того, чтобы позволить веб-проекту ссылаться на DAL, он ссылается на отдельный Composition Root-проект, который ссылается на оба DALи BLL.Композиция-корневой-проект имеет один класс с одним методом, который определяет привязки.Это дает следующие дополнительные преимущества:

• Только три слоя.Четыре слоя были бы непростой задачей для команды.
• Слабая связь гарантирована.Невозможно получить доступ к DAL из кода представления.
• Лучшая поддержка инструмента.Контроллеры остаются в стандартном расположении, поэтому «Добавить контроллер» доступен в контекстном меню, а отсутствующие виды выделены в коде контроллера.Также нет необходимости настраивать или писать собственную фабрику контроллеров.

Я не вижу больших недостатков.

Answer 3

Просто перейдите к варианту 1.

То, что у вас есть ссылка на сборку, не означает, что вы сломали SoC.

Веб-проект до сих пор ничего не знает о базовых реализациях,только интерфейс.

Веб-проект является «агрегатором» нижележащих слоев, поэтому имеет смысл знать о них для их настройки.

Answer 4

Я разделил проект MVC на две части примерно так, как описано в Ответе Марка Симанса.

MVCApplication является скромным объектом и требует ссылок на все, но не имеет никакого кода MVC, кроме global.asax (который ему нужен) и web.config (который, кажется, хочет),

Проект MvcUI ссылается только на интерфейсы и использует внедрение зависимостей.

Если вы поместите оба проекта (файлы .csproj) в один каталог, тогда папки Content, Controllers, Models, Scripts и Viewsвсе они фактически находятся в одном и том же месте, поэтому все инструменты работают.

На рисунке ниже показана идея решения.

Структура директории выглядит как-товот так

И у вас получится график зависимости вот так

Answer 5

Недавно я следовал тому же самому и подумал о MEF (Managed Extensibility Framework). С помощью MEF и рефлексии вы можете избавиться от этой ссылки DAL / Unit of work из корня композиции, и вам не нужно иметь 2 проекта MVC, как обсуждалось выше.