Инверсия управления и внедрение зависимостей в .NET Framework

Как StreamReader, так и StreamWriter можно рассматривать как примеры IoC / DI.

Каждый из них позволяет вам вводить другой объект Stream (или одну из его производных) для чтения / записи соответственно.

FileInfo fi = new FileInfo(@"C:\MyFile.dat");
StreamWriter sw = new StreamWriter(fi.Open());

Или:

MemoryStream ms = new MemoryStream();
StreamWriter sw = new StreamWriter(ms);

Оба позволят:

sw.Write("Hello world!");

Таким же образом, независимо от того, какой тип Stream вы внедрили при вызове конструктора.

Это пример того, как вы можете создать System.ComponentModel.Composition.Hosting.CompositionContainer в .NET 4:

var exeCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
var dircatalog = new DirectoryCatalog(".");
var aggregateCatalog = new AggregateCatalog(exeCatalog, dirCatalog);
var exportProvider = new CatalogExportProvider(aggregateCatalog);
var container = new CompositionContainer(exportProvider);

Это пример внедрения зависимости через аргументы конструктора. Поскольку использовался шаблон внедрения зависимостей, эти классы очень расширяемы: вы можете написать свою собственную реализацию ComposablePartCatalog и передать ее конструктору поставщика экспорта. Или вы можете обойти всю концепцию каталогов деталей и написать свою собственную реализацию ExportProvider .

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

Конечно - интерфейс IServiceProvider является частью Framework с версии 1.0. Это не DI, как обычно здесь обсуждается (с использованием "ядра"), но это IoC с использованием паттерна Service Locator.

Если вы покопаетесь в коде Windows Forms Designer, то увидите, что он обильно пестрит строками вроде этой:

IDesignerOptionService service = 
    (IDesignerOptionService)this.GetService(typeof(IDesignerOptionService));

Если вы работаете с Компонентом, то вы получаете доступ к нему через свойство Site. Это довольно распространенное и практически необходимое знание при создании пользовательских элементов управления.

Это Service Location, хрестоматийный пример. У вас есть общий IServiceProvider, который раздает абстрактные услуги, которые вы запрашиваете по типу услуг. Если вы когда-нибудь захотите создать пользовательские конструкторы - смарт-теги и так далее - то вам нужно знать все это. Это похоже и для ASP.NET.

_{P.S. Пожалуйста, не используйте IServiceProvider в новом коде. Это очень старый, негенеративный интерфейс. Если вы создаете многократно используемые библиотеки, для работы которых требуется IoC-контейнер, вам следует использовать Common Service Locator вместо него. Но даже не используйте этот, если вам не требуется, чтобы ваша библиотека была независима от библиотеки DI, используемой на уровне приложения; большинство контейнеров/ядер, специфичных для конкретной реализации, предлагают гораздо более богатые API, которые вы упустите, если будете привязывать себя к CSL.}

В настоящее время я читаю книгу The Art of Unit Testing Роя Ошерова. Он упоминает технику под названием Extract and Overload (то есть внедрение зависимости в класс через переопределение виртуального метода, который отвечает за возврат зависимости).

Мне кажется, я встречал различные примеры этой техники, например, вот эти:

• Настройка типа ADO.NET DataTable:
  Если вы производите от DataTable, у вас есть возможность переопределить различные методы, такие как GetRowType(), CreateInstance() и другие.

• Настройка конструкторов Workflow Foundation Activity (в .NET 3.5)
  Я не помню точный класс, но думаю, что если вы хотите создавать пользовательские конструкторы активности, вы получаете новые классы из существующих, и схема во многом та же; вы переопределяете виртуальный метод, который позволяет вам вернуть вашу пользовательскую зависимость фреймворку.

.NET, особенно в веб-контексте, предлагает Providers для определения альтернативных реализаций компонентов фреймворка. Фреймворк определяет абстрактный базовый класс, определяет одну или две конкретные реализации поверх него, и позволяет пользователям предоставлять свои собственные реализации, где это необходимо.

После определения пользователь не контролирует жизненный цикл своей реализации. Фреймворк берет на себя управление инстанцированием, настройкой и утилизацией.

Начните с System.Configuration.Provider.ProviderBase

.NET классы, реализующие ProviderBase:

• System.Configuration.ProtectedConfigurationProvider - шифрование и расшифровка данных защищенной конфигурации
  • System.Configuration.DpapiProtectedConfigurationProvider (concrete)
  • System.Configuration.RsaProtectedConfigurationProvider (concrete)
• System.Configuration.SettingsProvider - пользовательские настройки в архитектуре настроек приложения
  • System.Configuration.LocalFileSettingsProvider (конкретный)
  • System.Web.Profile.ProfileProvider
    • System.Web.Profile.SqlProfileProvider (конкретный)
• System.Web.Management.WebEventProvider - настройка обработки событий здоровья ASP.NET
  • System.Web.Management.BufferedWebEventProvider (конкретный)
    • System.Web.Management.MailWebEventProvider
      • System.Web.Management.SimpleMailWebEventProvider (concrete)
      • System.Web.Management.TemplatedMailWebEventProvider (concrete)
    • System.Web.Management.SqlWebEventProvider (concrete)
  • System.Web.Management.EventLogWebEventProvider (concrete)
  • System. Web.Management.IisTraceWebEventProvider (конкретный)
  • System.Web.Management.TraceWebEventProvider (конкретный)
  • System.Web.Management.WmiWebEventProvider (конкретный)
• System.Web.Security.MembershipProvider - пользовательское членство для служб членства
  • System.Web.Security.ActiveDirectoryMembershipProvider (concrete)
  • System.Web.Security.SqlMembershipProvider (concrete)
• System.Web.Security.RoleProvider - пользовательское управление ролями для служб управления ролями
  • System.Web.Security.AuthorizationStoreRoleProvider (concrete)
  • System.Web.Security.SqlRoleProvider (concrete)
  • System.Web.Security.WindowsTokenRoleProvider (concrete)
• System.Web.SessionState.SessionStateStoreProviderBase - хранилища данных состояния сессии
  • System.Web.SessionState.InProcSessionStateStore (бетон)
  • System.Web.SessionState.OutOfProcSessionStateStore (бетон)
  • System.Web.SessionState.SqlSessionStateStore (бетон)
• System.Web.SiteMapProvider - пользовательское хранилище постоянных данных SiteMap
  • System.Web.StaticSiteMapProvider
    • System.Web.XmlSiteMapProvider (конкретный)
• System.Web.UI.WebControls.WebParts.PersonalizationProvider - загружает и хранит данные персонализации от имени экземпляра WebPartPersonalization
  • System.Web.UI.WebControls.WebParts.SqlPersonalizationProvider (конкретный)

Примеры:

• Реализация Profile Provider
• Реализация Membership Provider