Зачем использовать сторонний контейнер DI через встроенный контейнер ASP.NET Core DI?

Поскольку в настоящее время отсутствует документация по теме DI – Injection Dependency . Может ли кто-нибудь помочь мне понять следующее:

  1. В чем разница между этими регистрациями?

    public void ConfigureServices(IServiceCollection services) { services.AddTransient(); services.AddScoped(); services.AddSingleton(); services.AddInstance(service); } 
  2. Каковы преимущества / недостатки использования встроенного DI над существующими решениями, такими как (NInject, Autofac, Structure Map)?
  3. Каковы текущие ограничения инъекции зависимостей по умолчанию (если таковые имеются)?

Для разработки продукта любого приложения с большим размером, которое следует принципам SOLID, встроенный контейнер DI vNext будет бесполезен, поскольку:

  • Это не поможет вам в проверке вашей конфигурации, что затрудняет диагностику проблем, возникающих из-за распространенных неправильных конфигураций. В приложении с достаточно большим размером на самом деле довольно сложно определить эти ошибки самостоятельно.
  • Нельзя применять сквозные проблемы с помощью перехватчиков или декораторов . Это делает обслуживание любого приложения с разумным размером действительно дорогостоящим.
  • Хотя он поддерживает отображение открытых общих абстракций для открытия общих реализаций, его реализация довольно наивна и не может работать с общими типами с ограничениями типа и более сложными отображениями общего типа.
  • Невозможно сделать условную регистрацию таким образом, чтобы регистрация вводилась только определенному набору потребителей.

Если вы начинаете с нового и простого проекта, мой совет – применить Pure DI (что означает компоненты с ручной проводкой без использования контейнера) и разрешить ваши типы, подключив ваш пользовательский IControllerActivator . Позже, когда такие функции, как пакетная регистрация и оформление, улучшат ремонтопригодность вашего корня композиции , переключитесь на одну из установленных библиотек DI, соответствующую вашим требованиям.

Здесь объясняется:

  • Transient – новый экземпляр создается каждый раз
  • Область – Единый экземпляр создается внутри текущей области. Это эквивалентно Singleton в текущей области действия
  • Синглтон. Создается один экземпляр и действует как одноэлементный
  • Экземпляр – конкретный экземпляр задается все время. Вы несете ответственность за свое первоначальное создание

Альфа-версия имела такие ограничения:

  • Он поддерживает только впрыск конструктора
  • Он может только разрешать типы с одним и только одним открытым конструктором
  • Он не поддерживает расширенные функции (например, для каждой области streamа или автоматического обнаружения)

Если вы не пишете действительно сложный продукт, то для вас должно быть достаточно контейнера DI. В других случаях вы можете попробовать библиотеки, которые вы уже упоминали, которые имеют расширенные функции.

Моим советом было бы начать с использования по умолчанию и изменить реализацию, когда (если) вы ударите то, что вы не можете с ним сделать.

В чем разница между этими регистрациями?

  • Transient – создается каждый раз, когда он извлекается
  • Скопированный – созданный экземпляр один раз для HTTP-запроса и будет доступен для жизни HTTP-запроса
  • Singleton – созданный экземпляр один раз и будет доступен для всего вашего приложения
  • Экземпляр – эквивалент singleton, за исключением того, что вы предоставляете экземпляр объекта вместо фреймворка, создающего экземпляр

Источник: http://www.khalidabuhakmeh.com/asp-vnext-dependency-injection-lifecycles , http://dotnetliberty.com/index.php/2015/10/15/asp-net-5-mvc6-dependency- инъекции-в-6-шагов /

Чтобы ответить на ваш первый вопрос: кажется, что документы ASP.NET были обновлены и теперь четко указывают, для чего каждый тип регистрации:

Сервисы ASP.NET могут быть настроены со следующими сроками службы:

преходящий

Временные службы времени жизни создаются каждый раз, когда они запрашиваются. Эта пожизненная работа лучше всего подходит для облегченного, безгосударственного обслуживания.

Scoped

Приобретенные службы жизненного цикла создаются один раз за запрос.

одиночка

Услуги Singleton life life создаются при первом запросе, а затем каждый последующий запрос будет использовать один и тот же экземпляр. Если вашему приложению требуется однопользовательское поведение, рекомендуется использовать контейнер службы для управления временем жизни службы, вместо того, чтобы внедрять шаблон дизайна singleton и управлять жизнью вашего объекта в classе самостоятельно.

Экземпляр [только до RTM!]

Вы можете добавить экземпляр непосредственно в контейнер сервисов. Если вы это сделаете, этот экземпляр будет использоваться для всех последующих запросов (этот метод создаст экземпляр Singleton). Одним из ключевых различий между службами экземпляра и услугами Singleton является то, что служба экземпляра создается в ConfigureServices, а служба Singleton – при первом запросе.


Обновлено в RTM

Обратите внимание, что в Asp.Net Core RTM docs экземпляр был удален. Экземпляры в основном такие же, как Синглтон, но у них была другая семантика инициализации (Singleton был ленивый загружен). Но теперь нет API AddInstance, только AddSignleton, который может принимать уже созданный экземпляр.

Давайте будем гением компьютера.