Резюме

DI-контейнер может стать чрезвычайно полезным инструментом, если вы правильно его используете. Самое важное – понять, что использование механизма внедрения зависимостей никоим образом не зависит от использования DI-контейнера. Приложение может состоять из множества слабо связанных классов и модулей, и ни один из этих модулей не должен ничего знать о контейнере. Наиболее эффективный способ убедиться в том, что код приложения не осведомлен ни об одном DI-контейнере, – жестко реализовать паттерн Register Resolve Release в Composition Root. Это эффективно предостережет вас от случайного применения анти-паттерна Service Locator, потому что он заключает контейнер в небольшую изолированную область кода.

Если использовать DI-контейнер таким образом, то он станет движком, который берет на себя заботу о большей части инфраструктуры приложения. Он формирует диаграмму объектов на основании его конфигурации. Это может быть особенно существенно, если вы применяете конфигурацию, базирующуюся на соглашениях – при соответствующей реализации он может заботиться о формировании диаграммы объектов, и вы можете сконцентрировать ваши усилия на добавлении новых классов, реализующих новые возможности. Контейнер будет автоматически обнаруживать новые классы, которые соответствуют установленным соглашениям, и делать их доступными для пользователей.

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

Эта глава подытоживает первую часть книги. Целью первой части было знакомство с DI. Предыдущие главы в общих чертах знакомили с механизмом внедрения зависимостей, тогда как данная глава объясняет то, как DI-контейнеры относятся к DI, а также в общих чертах объясняет процесс проектирования приложения. Я подумал, что исторический обзор DI-контейнеров в .NET экосистеме как раз подходит для завершения главы, чтобы действительно ввести в игру различные контейнеры.

Глава представляет Composition Root и Register Resolve Release как два мини-паттерна, которые относятся к DI-контейнерам. В следующей главе мы сосредоточимся на паттернах проектирования.

или RSS канал: Что новенького на smarly.net