ASP.NET: можно ли вынести контроллеры в отдельный проект при использовании IoC?
Создал ASP.NET WEB API приложение через шаблон визуал студии, студия сгенерила запускаемый веб-проект WebApi, в котором создала дефолтный контроллер. Дальше я создал проекты DataAccess, BusinessLogic и Domain. В Domain находятся сущности из БД и интерфейсы для DataAccess и BusinessLogic, соотвественно, DataAccess и BusinessLogic реализуют эти интерфейсы и ссылаются на Domain. Проект WebApi тоже ссылается на Domain, но не ссылается на DataAccess и BusinessLogic, т.к. WebApi ничего не знает о реализациях, а знает только об интерфейсах, а реальные DataAccess и BusinessLogic подставляются через IoC-контейнер (для этого пришлось также переопределить инициализацию контроллеров через тот же IoC-контейнер, кто с IoC работал, тот поймет).
В предыдущих проектах я видел только, что IoC-контейнер инициализировался прямо внутри проекта WebApi, но из-за этого приходилось в WebApi добавлять ссылки на DataAccess и BusinessLogic. И тут я подумал, для чего WebApi ссылаться на DataAccess и BusinessLogic, если он все-равно с ними не должен никогда работать напрямую, а только через интерфейсы из Domain. Тут я подумал, что инициализацию IoC можно оставить в сгенеренном студией запускаемом веб-проект WebApi, где изначально располагался контроллер, а сам контроллер вынести в отдельный проект, например, WebApiControllers. В результате для проекта WebApiControllers можно будет не добавлять референсы на DataAccess и BusinessLogic, а только на Domain, и в нем не будет лишних зависимостей. Т.к. инициализацию нужных контроллеров я переопределил со стандартной и сам разруливаю через мной настроенный IoC, то проблем с вызовом контроллеров при выносе их в отдельный проект не будет.
Можно ли сделать такую схему, или это очень плохо? Я никогда на проектах не видел, чтобы контроллеры выносили в отдельный не стартовый проект.
Или оставить все как есть и не стоит париться из-за того, что из-за инициализации IoC пришлось привязать проект WebApi к проектам DataAccess и BusinessLogic?
Я обычно в подобной ситуации делаю отдельный проект IoC, который знает о DataAccess и BusinessLogic. После этого делаю в нем екстеншен метод для IServiceCollection в котором все регестирую, а уже в WebApi его вызываю
Я не могу вынести IoC в отдельный проект, т.к. мой IoC должен зарегистрировать контроллеры, т.к. контроллеры приходится создавать не автоматически (как по умолчанию), а вручную через IoC.Resolve, потому что контроллеры принимают в конструкторе зависимости, а автоматическое создание контроллеров не работает с параметризованными конструкторами. Из-за этого, если вынести IoC в отдельный проект, а контроллеры оставить в стартующем проекте (webApi), то получается, что стартующий проект (webApi) должен ссылаться на IoC для инициализации IoC, а IoC должен ссылаться на стартующий проект (webApi) для того, чтобы получить из него контроллер для регистрации. Получается круговая зависимость, которая невозможна. Интересно, а как вы это у себя разруливали?
Я сейчас вынес контроллеры в отдельный проект, а IoC оставил в стартующем проекте, все работает, но, конечно, в стартующем проекте остаются референсы на библиотеки, которые там больше не нужны, и их нужно перенести в проект контроллеров, а этой геморойно. Но меня больше беспокоит вопрос, что если такую мою схему разбивки на проекты кто-нибудь из опытных разрабов увидит, то меня сразу за лузера посчитают, или, наоборот, они даже оценят схему, т.к. схема имеет право на жизнь (просто я в жизни ни разу такой разбивки не видел, когда контроллеры отдельно от стартующего проекта выносят)?
Получается, что регистрация компонентов для контейнера будет разнесена по разным проектам. Не лучше ли все в одном? И референсы на IoC-библиотеку будут только в одном проекте, а не в многих.
Вспомните как вы подключаете EF, это проиходит приблизительно так:
не, я не так делаю. я так понял, это какой-то встроенный в asp.net core ioc ? Я юзаю .net framework и ioc castle windsor.
т.е. регистрация компонетов уже разнесена по разным проект.
Т.е., я так понял, в вашей структуре есть IoC-проект, а все остальные проекты (webApi, DataAccess, BusinessLogic, Domain) референсятся на IoC-проект, и каждый проект сам себя регистрирует в IoC? С webApi понятно - он запускающийся, он может себя зарегать. Не понятно, как себя регистрируют остальные сервисы, т.к. если они регистрируют себя сами, то webApi должен напрямую вызвать их методы регистрации, но webApi ничего не должен знать об остальных сервисах.
Я у себя сделал обратную картину - есть запускающийся Ioc , он знает обо всех сервисах, сервисы не знают друг о друге, Ioc сам внутри себя регистрирует все сервисы
Станислав Силин, Картинку понял, но не понял, как webApi регистрирует себя в IoC, если webApi - стартующий проект и он не знает про Ioc?
У меня схема такая вышла:
Теперь понял. Изначально я так и хотел сделать, но меня остановило то, что я все хотел регистрировать внутри IoC, но при такой схеме внутри IoC можно регистрировать dataLayer и Business, а webApi нужно регистрировать в webApi. В итоге я инвертировал зависимость между webApi и IoC, и у меня все теперь регистрируется в IoC.
Средний
