0

У меня есть 4 Проекты в раствореКак решить Завис в Dependency

  • DAL_Project
  • BLL_Project
  • Interface_Project
  • WebApi_Project

Interface_Project имеет два интерфейса ICar_DAL и ICar_BLL

DAL_Project имеет класс Car_DAL, который реализует ICar_DAL

BLL_Project имеет класс Car_BLL, который реализует ICar_BLL и его конструктор принимает ICar_DAL

WebApi_Project имеет контроллер апи CarApiController и его конструктор принимает ICar_BLL

разрешение зависимостей конструктора WebAPI контроллера осуществляется с помощью Unity.WebApi это в Bootstrapper.cs:

container.RegisterType<ICar_BLL, Car_BLL>(); 

это сработало бы, если бы мой Car_BLL не требовал ICar_DAL в своем конструкторе.

, чтобы сделать его работу я могу сделать некоторые вещи, как это:

container.RegisterType<ICar_BLL, Car_BLL>(); 
container.RegisterType<ICar_DAL, Car_DAL>(); 

но это означало бы, что мне нужно, чтобы добавить ссылку на DAL_Project в моем WebApi_Project что-то я никогда не хотел бы делать. DAL_Project следует относить только BLL_Project

Как я могу решить эту проблему?

+0

Возможный дубликат [Ioc/DI - Почему мне нужно ссылаться на все слои/сборки в приложении ввода?] (Http://stackoverflow.com/questions/9501604/ioc-di-why-do-i -have-to-reference-all-layers-assemblies-in-entry-application) – Steven

+0

Спасибо, Стивен ... ваш ответ и другие ответы в этом посте дали мне немного больше возможностей для изучения, я рассмотрю концепцию композиции Root более подробно. Я думаю, что это был недостающий кусок. Еще раз спасибо. –

ответ

2

но это означало бы, что мне нужно, чтобы добавить ссылку на DAL_Project в моем WebApi_Project что-то я никогда не хотел бы делать.

О, похоже, у вас есть некоторые недоразумения в отношении того, как должна выполняться зависимость, если вы этого не хотите. Контейнер DI сконфигурирован в самом внешнем слое вашего приложения, которое на самом деле является хостом. Он также упоминается как Composition Root. В вашем случае это хостинг-приложение вашего веб-API. Если вы используете ASP.NET для размещения своего веб-API, тогда это подходящее место для создания корня композиции и ссылки на все остальные базовые проекты.

Лично в сложном проекте у меня есть классная библиотека ProjectName.Composition, которая служит мне как Корень композиции. здесь я настраиваю контейнер DI, и это проект, который ссылается на все остальные. Очевидно, для того, чтобы настроить корень DI, вам нужны все зависимые проекты и реализации. Эта сборка .Composition является ссылкой на приложение-хостинг и метод Bootstrapper.Initialize, вызываемый в методе Initialize приложения-хостинга.

  • В случае хоста ASP.NET, который был бы Application_Start в Global.asax
  • В случае настольного приложения или сам-хоста, который будет являться Main методом, который является точкой входа.
+0

Спасибо Дарин. Думаю, у меня есть твоя точка корня композиции. Я прочитаю об этом больше. Если Root Coposition должен быть моим проектом Web Api, считаете ли вы, что это хорошая идея оставить проект Web Api просто выполнить работу с корневым составом и вывести контроллеры из него в новый проект библиотеки классов. Тогда все проекты будут иметь только ссылки на InterfaceProject, и проект WebAPI будет иметь ссылки на каждый проект в качестве его корня композиции. У вас будет правильная архитектура? –

+0

Не забывайте, что слой является логическим разделением, а не физическим. Слои должны уменьшить сложность, сборки предназначены для создания единиц развертывания. Таким образом, с точки зрения наслаивания, хорошо иметь несколько слоев в одной и той же сборке. Корень состава (CR) является собственным слоем, но поскольку CR специфичен для конечного приложения, он всегда будет развернут с вашим приложением WebAPI. И даже если ваша сборка WebAPI ссылается на все другие сборки, ваш пользовательский интерфейс веб-интерфейса API не ссылается на все остальные слои. С другой стороны, слой CR будет ссылаться на все остальные слои. – Steven

+0

Значит ли это, что я иду в правильном направлении, перемещая контроллеры и представления в своих отдельных проектах из проекта web api. И оставить проект web api как слой CR? Также я предполагаю, что то же самое можно применить к веб-приложению MVC, где веб-приложение - CR, а его контроллеры - представления (UI) - в отдельных проектах, которые не ссылаются на все другие проекты. Последнее: сохранить все мои интерфейсы в отдельном проекте интерфейса - это хорошая идея? –