XaocCPS Aug 12 2015 at 10:47

Готовим ASP.NET5, выпуск №3 — внедрение зависимостей по-новому

5 min

18K

Microsoft corporate blogWebsite development*.NET*ASP*Visual Studio*

+17

Comments 20

Alvaro Aug 12 2015 at 11:10

Я так понимаю, использование встроенного DI-контейнера актуально для общих инфраструктурных вещей. Для сервисов бизнес-логики остаются привычные DI-контейнеры с поддержкой регистрации декораторов, коллекций и т.д.

kekekeks Aug 12 2015 at 11:19

Вообще говоря есть адаптеры к большинству DI-библиотек, реализующие IServiceProvider. Так что подключаете свой любимый контейнер и едете дальше.

Alvaro Aug 12 2015 at 11:47

Есть небольшая проблема: нет ни одного DI-контейнера, полностью соответствующего поведению контейнера ASP.NET 5. Например, для Unity для регистрации коллекции нужно несколько раз регистрировать сервис. В обсуждении использования Simple Injector с ASP.NET 5 описываются эти проблемы

kekekeks Aug 12 2015 at 14:24

У того же Ninject-а, вроде, указанной проблемы с коллекциями нет. Коллекции с одним элементом вполне спокойно инжектит. Аналогично у TinyIoC.

ilya-chumakov Aug 12 2015 at 11:11

одна их первых зависимостей, о которых мы задумаемся для использования DI – это DbContext

Полюбопытствую: часто ли Вы передаете DbContext в контроллер в реальных приложениях?

Gbdrm Aug 12 2015 at 11:21

Не обязательно же его передавать в контроллер. Но в репозиторий или другой объект с уровня доступа к данным приходится. Просто это хороший пример, который нагляден в демо-приложениях.

mird Aug 12 2015 at 11:15

Хотелось бы узнать ответ на вопрос в чем преимущество использования этого контейнера перед другими?

kekekeks Aug 12 2015 at 11:21

Искоробочность.

centur Aug 12 2015 at 14:21

А при наличии nuget, которым уже фреймворк можно по кускам собирать, это все еще аргумент? Просто есть прекрасные производительные контейнеры которые легко подключаются и удобно настраиваются — какой смысл брать «ис коропки»? Тут как-то возникает подозрение на рецидив любимого not invented here синдрома.

XaocCPS Aug 12 2015 at 14:41

вопрос в том, что если фреймворк внутри себя использует инъекции, нужно ли для этого тащить за собой сторонний инструмент или стоит реализовать легкие контейнеры как часть фреймворка?

mird Aug 12 2015 at 18:06

Если б он еще умел все то, что умеют остальные контейнеры… Вот что у него, например, с внедрением Func, если мы зарегистрировали T? Ну и да, а если я вообще не хочу тащить контейнер, а хочу Pure DI? Нафига мне это в инфраструктуре? Учитывая, что в MVC DI контейнер встраивался легко и не принужденно то ли с первой то ли со второй версии, зачем было тратить время на эту разработку не понятно.

centur Aug 13 2015 at 04:21

Ну это как — зачем тащить решарпер если студия тоже умеет рефакторить. Я понимаю любовь некоторых разработчиков к уютненькому «MS-из-коробки», была бы возможность — они бы и из студии не вылазили и пользовались только встроенными тулзами. Но таким способом вы же только стимулируете вендорлок подход и плодите разработчиков которые дальше MSDN в интернете не ходят…

XaocCPS Aug 13 2015 at 14:28

Ваша же логика подтвреждает мои слова: никто решарпер не включает в поставку VS, вместо этого предлагают свои инструменты, может быть не такие глубокие, как сторонние.

Никто не запретил (по факту наоборот, сделал более широким) применение сторонних контейнеров в ASP.NET.

centur Aug 13 2015 at 14:51

Даже не буду спорить, бесполезно. Для меня это выглядит как размывание аудитории. Вместо 14 конкурирующих контейнеров — у нас теперь будет 15, xkcd #927…

У вас же была Unity, везде ее пихали, народ так ужаснулся что написали кучу приличных контейнеров, лишь бы не Unity. С EntityFramework — очень похожая история. Начиная с расцвета microORM и заканчивая тем, что похоже сама команда EF поняла что нахрен этот велосипед, давайте выпилим новый с нуля.

Как прекрасно было когда вместо своего DataContractSerializer, MS взяла и задействовала Newtonsoft.Json.NET — в итоге это стандарт де-факто, прекрасная библиотека и легко найти ответы и куча примеров.

Ну вот так, без сарказма, вы можете рассказать — а для чего нужен именно свой. Какая практическая долгосрочная цель у этого контейнера — что, МС будет в него вкладываться, создавать и поддерживать сообщество, допиливать фичи для лучшего покрытия edge-cases, исправлять сложные дедлок баги когда они полезут? Бюджет будет на контейнер дальше выделяться? не на asp.net а именно на конкретную вот эту область. Какие планы на дальнейшее развитие этого участка? Или это чтобы hello-world сэмплы было проще писать?

mird Aug 13 2015 at 15:13

Мне кажется, тут нет смысла говорить о политике Microsoft. Если бы это была политика Microsoft, тут был бы Unity или MEF2. Просто команде разрабатывающей MVC захотелось написать свой собственный контейнер с блекджеком. Ну бывает. Бтв, я не заметил, чтобы Unity везде пихали (в смысле настойчиво продвигали). EntityFramework с этой точки зрения более навязчив (по умолчанию добавленный пакет в ASP.Net MVC шаблон проекта).
Я то надеялся, что мне расскажут какие новые возможности в контексте MVC приложения дает этот контейнер, по сравнению с другими, но что-то единственное преимущество которое привели — искоробочность, которое я за преимущество не считаю.

centur Aug 13 2015 at 15:18

Когда юнити зарелизили — продвигали довольно настойчиво, потом как-то поубавилось энтузиазизма. А EF это да, как и стандартные шаблоны — так много приходится выкорчевывать, что уже на автомате ищешь только Empty …

mird Aug 13 2015 at 16:12

Когда юнити зарелизили — продвигали довольно настойчиво, потом как-то поубавилось энтузиазизма.

Ну это нормально. Надо же чтобы на него обратили внимание и попробовали.

Taritsyn Aug 12 2015 at 11:33

Хорошая статья. Хотелось бы увидеть продолжение не тему использования механизма Options.

Gbdrm Aug 12 2015 at 11:51

Спасибо, одна из причин почему она появилась – ваш комментарий о DI к моей предыдущей статье.

Dim0FF Aug 12 2015 at 17:51

Спасибо за статью.

Если мы используем EntityFramework в нашем приложении, то одна их первых зависимостей, о которых мы задумаемся для использования DI – это DbContext. Это позволит нам написать менее завязанный на DbContext код, легче тестировать такой функционал и т.д.

А можете показать пример удобного тестирования при инжекте DbContext?