Резюме

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

Некоторые фреймворки облегчают этот процесс. При написании консольных приложений и Windows клиентов (WPF или Windows Forms) мы более или менее напрямую контролируем то, что происходит в точке входа в приложение. Это обеспечивает нас различными и легко реализуемыми Composition Root в точке входа.

Другие фреймворки, например, ASP.NET MVC и WCF, заставляют нас поработать немного усерднее, но они все же предоставляют швы, которые мы можем использовать для того, чтобы определить то, как приложение должно быть скомпоновано. ASP.NET MVC уже был создан с замыслом механизма внедрения зависимостей, поэтому построение приложения такой же простой процесс, как и реализация пользовательского IControllerFactory и регистрация его с помощью фреймворка. Кажется, что в WCF шов находится почти случайно, но, несмотря на то, что это более обходной путь, нежели реализация единичного интерфейса, мы все еще можем достичь всех ценных свойств механизма внедрения зависимостей, которые только могли бы пожелать.

Остальные фреймворки являются явно DI-недружественными и требуют от нас использования конструктора по умолчанию для соответствия им. ASP.NET (Web Forms) является самым известным из них, но еще одними примерами являются также и PowerShell, и Managed MMC SDK. Эти фреймворки управляют жизненными циклами классов, которые мы предоставляем, поэтому единственный вариант – рассматривать каждый класс как отдельный Composition Root. Это требует много затрат, поэтому я лично предпочитаю использовать DI-дружественные фреймворки, если у меня есть выбор.

Без композиции объектов нет и механизма внедрения зависимостей, но вы, возможно, еще не осознали полностью роль жизненного цикла объектов, когда мы переносили создание объектов из используемых классов. Вам может показаться само собой разумеющимся, что внешний объект, выполняющий вызов, (чаще всего DI-контейнер) создает новые экземпляры зависимостей – но когда высвобождаются внедряемые зависимости? И что если внешний объект, выполняющий вызов, решит не создавать новые экземпляры все время, а вместо этого передаст вам существующий экземпляр? Это темы обсуждения для следующей главы.

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