What is *Dependency Injection in .NET* by Mark Seemann about?

*Dependency Injection in .NET* is a practical guide to implementing dependency injection (DI) in .NET applications. It explains how DI reduces tight coupling between components using patterns like Constructor Injection and integrates with frameworks like ASP.NET MVC. The book also covers DI containers (e.g., StructureMap, Castle Windsor) and anti-patterns to avoid, helping developers build maintainable, testable code.

Who should read *Dependency Injection in .NET*?

This book is ideal for C# developers seeking to master DI principles, whether they’re new to DI or experienced. It’s particularly valuable for engineers working with .NET frameworks like ASP.NET MVC or transitioning to DI-enabled architectures. Technical leads and architects will also benefit from its coverage of object lifetime management and DI refactorings.

Is *Dependency Injection in .NET* worth reading?

Yes—the book won the 2013 Jolt Award for Productivity and remains a definitive resource. It balances theory with hands-on C# examples, critiques common pitfalls (e.g., Service Locator anti-pattern), and demonstrates integration with both Microsoft and open-source DI tools. Developers praise its clear explanations of advanced topics like interception and composition roots.

What are the key DI frameworks covered in *Dependency Injection in .NET*?

Mark Seemann details six major frameworks: **StructureMap**, **Castle Windsor**, **Unity**, **Spring.NET**, **Autofac**, and **MEF**. The book compares their configuration approaches, lifetime management, and interception capabilities, helping readers choose the right tool for projects ranging from legacy apps to modern microservices.

How does *Dependency Injection in .NET* address anti-patterns?

The book dedicates a section to DI anti-patterns like *Control Freak* (overusing `new` operators) and *Bastard Injection* (mixing default and injected dependencies). It provides refactoring strategies, advocating for explicit composition roots and constructor injection to avoid hidden dependencies and improve testability.

What is the "Composition Root" concept in the book?

A **Composition Root** is the single location where an application’s object graph is assembled. Seemann emphasizes centralizing dependency configuration here rather than scattering it across components. This pattern simplifies maintenance, ensures consistent lifetime management, and reduces coupling between modules.

How does *Dependency Injection in .NET* relate to .NET Core’s built-in DI?

While the book predates .NET Core, its principles apply directly to Microsoft’s built-in `IServiceProvider`. Concepts like lifetime scopes (transient vs. singleton) and interface-based design align with .NET Core’s DI implementation. The book’s framework-agnostic patterns help developers adapt to newer versions like .NET 7/8.

What real-world applications does the book’s "Comprehensive Example" demonstrate?

The example illustrates DI in a full-stack .NET app, covering database integration, service layer decoupling, and UI-layer dependency management. It shows how DI enables easier testing, modular replacements (e.g., swapping mock repositories), and scalable architecture decisions.

Внедрение зависимостей в .NET book cover

Краткое содержание «Внедрение зависимостей в .NET»

Mark Seemann

4.43(777 Reviews)

Обзор: Краткое содержание «Внедрение зависимостей в .NET»

Революционизируйте свой код на C# с помощью книги «Внедрение зависимостей в .NET» — основополагающего руководства Марка Симана, которое изменило подход разработчиков к принципам SOLID. Книга, которая сделала слабое сопряжение крутым еще до того, как микросервисы стали мейнстримом.

Выберите способ повествования

Изучите Краткое содержание «Внедрение зависимостей в .NET» в разных стилях обучения

Те же идеи из Внедрение зависимостей в .NET. Выберите подходящие вам голос, глубину и темп. Меняйте в любое время.

Глава 1

Холодильник на вашей кухне

Начнем с довольно неожиданного утверждения. Самая главная идея в архитектуре профессионального программного обеспечения — это ровно та же идея, почему у вашего холодильника есть обычная электрическая вилка, а не кабель, замурованный прямиком в стену. Марк Симан годами наблюдал за тем, как разработчики пишут код. В день релиза этот код работает идеально. Но пройдет совсем немного времени, и прикоснуться к нему становится почти невозможно. И дело вовсе не в том, что логика была неверной. Просто всё было припаяно напрямую друг к другу. Примерно так раньше строили дома: провод от холодильника сращивали с проводкой прямо внутри стены. Захотели новый холодильник? Вызывайте электрика. Захотели передвинуть? Придется ломать гипсокартон. А потом кто-то придумал розетку. Розетке абсолютно всё равно, какой марки ваш холодильник. Она дает стандартный разъем, фиксированную форму и гарантированное питание. Любой прибор, подходящий под эту форму, будет работать. Холодильник понятия не имеет, как именно создается электричество: на угольной станции, на солнечных батареях или в дизельном генераторе в подвале. Он просто знает, что получит ток через этот разъем. В этом и заключается суть внедрения зависимостей. Это не какой-то инструмент. Это не библиотека, которую нужно устанавливать. Это архитектурный подход. Вы строите программу так, чтобы элементы, выполняющие реальную работу, никогда сами не искали и не захватывали то, от чего они зависят. Вместо этого все зависимости передаются им извне через стандартный разъем. Книга Симана, получившая престижную премию Jolt Award и ставшая фундаментальным трудом по этой теме, доказывает простую вещь. Именно эта единственная привычка, если следовать ей системно, отделяет живой, гибкий код от застывшего и окаменевшего. И вот почему это важно, если убрать всю громкую терминологию. Симан честно признает: внедрение зависимостей постоянно понимают неправильно. Многие думают, что это просто мудреный способ сделать динамическое связывание. Это не так. Другие уверенны, что всё это нужно только ради юнит-тестов. Тестам это действительно помогает, но это лишь приятный побочный эффект, а не главная цель. Некоторые считают, что вам обязательно нужен специальный контейнер внедрения зависимостей — такой умный фреймворк, который сам автоматически связывает объекты. Вовсе нет. Вы можете сделать всё это вручную. Симан называет такой подход «чистый DI», и именно так работают многие серьезные системы. Наконец, внедрение зависимостей путают с паттерном Сервис-локатор. Внешне он похож, но на самом деле, как мы убедимся позже, это полная противоположность правильному подходу. В ближайшие полчаса мы разберем всю эту механику изнутри. Мы не будем ограничиваться банальными фразами вроде «слабая связанность — это хорошо». Мы пошагово разберем, как взять запутанное приложение с жесткими связями и вывернуть его наизнанку, чтобы оно держалось на разъемах, а не на пайке. Мы увидим, как сделать время жизни объекта контролируемым процессом, а не случайностью. И как «навесить» на ваш бизнес-код логирование, проверки безопасности и повторные попытки вызовов так, чтобы сам бизнес-код о них даже не догадывался. Начнем с того же, с чего начинает Симан: с зависимостей, которые действительно заслуживают такого внимания.

Глава 2

Зависимости, о которых действительно стоит беспокоиться

Далеко не каждая зависимость в программе создаёт проблемы. Это первое, с чем нужно разобраться. Иначе легко поддаться соблазну и начать заворачивать абсолютно всё в интерфейсы и внедрять их извне. А это утомительно и бессмысленно. Симан проводит четкую грань между стабильными и volatile, то есть изменчивыми зависимостями. Стабильная зависимость — это, например, стандартный класс из базовой библиотеки классов .NET, обычная строка, список или базовая арифметика. Она детерминирована. Она ведет себя одинаково каждый раз. Она никуда не исчезнет, и вы никогда не будете менять ее на что-то другое. Нет никакого смысла внедрять обычную строку через интерфейс. Изменчивая зависимость — совсем другое дело. Она изменчива, если требует настройки внешнего окружения: подключения к базе данных, сетевого вызова, работы с файловой системой. Она изменчива, если ее еще вообще не существует — например, вы пишете код сегодня, а модуль, с которым нужно связаться, параллельно делает другая команда. И она изменчива, если ведет себя недетерминированно: дает разные ответы в зависимости от времени суток, состояния внешней системы, генератора случайных чисел или текущей даты. Базы данных, веб-сервисы, системные часы, генераторы случайных чисел — вот те части кода, которые, по словам Симана, заслуживают быть спрятанными за интерфейсом и переданными извне, а не создаваться напрямую там, где они потребовались. Это различие крайне важно. Оно показывает, куда именно стоит тратить усилия. Вам не нужно устраивать театр с внедрением зависимостей на каждом шагу. Это нужно ровно там, где ваше приложение соприкасается с непредсказуемым внешним миром. Чтобы сделать эту мысль наглядной, Симан рассказывает историю. Разработчик по имени Мэри Роуэн делает интернет-магазин. Веб-слой на ASP.NET Core, база данных через Entity Framework Core, плюс логика расчета скидок и вывода товаров на главную страницу. Первая версия этого приложения написана Симаном намеренно плохо. Это наглядный пример того, что происходит, когда вы полностью игнорируете разницу между стабильными и изменчивыми зависимостями. Коллега по имени Йенс подталкивает Мэри к решению, которое кажется самым простым и прагматичным: просто вызывать контекст базы данных CommerceContext напрямую из бизнес-логики, из класса ProductService. Создать объект прямо там через new и не усложнять жизнь. Это работает? Работает. Компилируется? Да. Можно отдавать в продакшн. Вот только теперь ProductService намертво приварен к Entity Framework. Симан подробно разбирает, что произойдет, когда вы попытаетесь протестировать этот код, поменять слой данных или просто верстать интерфейс, пока кто-то другой меняет схему базы. У вас ничего не выйдет. Если нарисовать граф зависимостей стрелками, то пользовательский интерфейс зависит от бизнес-логики, а бизнес-логика напрямую зависит от конкретного слоя данных. Поменять интерфейс можно без проблем. Но стоит попытаться поменять слой данных — и ошибка каскадом пройдет через всю бизнес-логику прямо в контроллер. Одно изменение внизу системы заставляет переписывать всё на самом верху. Симан ставит точный диагноз: проблема не в том, что Entity Framework плох. Проблема в том, что ProductService — элемент бизнес-логики, который должен быть стабильным и абстрактным — взял и напрямую доверился изменчивой детали. И простым патчем тут не обойтись. Нужна инверсия.

Следите за каждым словом во время прослушивания

Читайте Краткое содержание «Внедрение зависимостей в .NET» вместе с аудио: каждое слово подсвечивается в реальном времени.

Глава 3

Выворачиваем связи наизнанку

Перейдем к самой механике. Как именно взять этот плотно связанный клубок и инвертировать его? Этот прием называется принципом инверсии зависимостей. Как только вы его поймете, он покажется вам почти фокусом. Вместо того чтобы ProductService запрашивал конкретный класс работы с базой, вы создаете интерфейс IProductRepository. И кладете его внутрь самого слоя бизнес-логики, прямо рядом с ProductService. Не в слой данных, а именно в бизнес-логику! Это тот шаг, который многие упускают, хотя в нем и кроется весь секрет. Бизнес-логика сама формулирует, что именно ей нужно для работы. А слой данных теперь обязан подстроиться под эти требования и реализовать их. Посмотрите, что происходит со стрелками на схеме. Раньше бизнес-логика зависела от базы данных. Теперь база данных зависит от бизнес-логики. Потому что класс SqlProductRepository, находящийся в слое данных, реализует интерфейс IProductRepository, принадлежащий бизнес-логике. Направление зависимости физически развернулось на противоположное! Хотя сам порядок вызова методов во время работы программы вообще не изменился. ProductService по-прежнему просит данные и получает их. Но на архитектурном уровне бизнес-логика теперь владеет абстракциями. А всё изменчивое — база данных, веб-фреймворк — указывает внутрь, на бизнес-логику, а не наоборот. Симан полностью переписывает приложение Мэри по этому принципу, двигаясь снаружи внутрь. Контроллер теперь зависит только от IProductService. Сам ProductService при создании получает IProductRepository и IUserContext через свой конструктор, а не ищет их сам. Конкретный класс SqlProductRepository, который действительно работает с Entity Framework и CommerceContext, полностью живет в слое данных и реализует интерфейс бизнес-логики. Появляется и адаптер AspNetUserContextAdapter, который берет данные пользователя из ASP.NET и переводит их в форму, понятную IUserContext. В итоге бизнес-логика даже не подозревает о существовании ASP.NET. Если нарисовать диаграмму после такого рефакторинга, вы увидите удивительную вещь. У слоя бизнес-логики вообще нет исходящих стрелок. Ноль. Он стоит в самом центре — чистая бизнес-логика. И веб-интерфейс, и база данных смотрят на него и реализуют его интерфейсы. Теперь вы можете полностью заменить Entity Framework на другую базу данных. ProductService этого даже не заметит: его не придется ни менять, ни перекомпилировать. Вот так выглядит настоящая гибкость архитектуры. Но тут возникает логичный вопрос, и Симан разбирает его напрямую. Если ProductService просто просит IProductRepository в своем конструкторе и сам ничего не создает, то кто-то же должен в конечном счете создать реальный SqlProductRepository и передать его? Кто выполняет эту работу? На этом вопросе весь подход либо работает, либо рушится.

Глава 4

Единственное место, где разрешено слово new

Ответ прост: в приложении должно быть ровно одно специально отведенное место. Оно называется «корень композиции». Симан определяет его как единую логическую точку, расположенную как можно ближе к старту приложения, где собирается весь граф объектов. Все изменчивые зависимости создаются именно здесь и передаются дальше по цепочке тем объектам, которым они нужны. Во всем остальном коде действует железное правило: ни один изменчивый объект не может создаваться через обычный оператор new за пределами этого места. На первый взгляд это кажется невозможным. Если сервису нужен репозиторий, репозиторию нужна строка подключения, а строке подключения нужна конфигурация — неужели корень композиции должен знать вообще обо всем в системе? Симан объясняет: это лишь иллюзия раздувания зависимостей. Дело не в том, что корень композиции неожиданно должен решать десятки чужих задач. Дело в транзитивности. Если A зависит от B, а B зависит от C, то кто-то где-то в любом случае должен создать C, чтобы получить A. Так было всегда. Корень композиции просто делает эти связи видимыми, а не прячет их в десятках разных конструкторов по всему проекту. Как это выглядит на практике? Представьте консольную версию приложения Мэри — небольшую утилиту для обновления курсов валют. Точка входа в программу, метод Main — это и есть корень композиции. Сначала он загружает конфигурацию: строку подключения, API-ключ и всё, что нужно из внешнего мира. И только потом начинает сборку. Сначала создаются самые базовые изменчивые элементы — например, парсер валют, подключенный к базе данных. Затем они передаются в объекты уровнем выше. И так далее, пока не будет собран весь готовый к работе граф объектов. После этого вызывается один единственный метод, запускающий всю работу. Этот паттерн вообще не зависит от фреймворков. Это обычные конструкторы, вызванные в правильном порядке, в одном файле, в момент старта приложения. Вот что имеют в виду, когда говорят «чистый DI». Никакой магии, никакой reflection, никаких контейнеров. Просто осознанная и централизованная сборка объектов отдельно от бизнес-логики. В ASP.NET Core всё работает по тому же принципу, но подключается к специальной точке расширения — интерфейсу IControllerActivator. Фреймворк вызывает его каждый раз, когда нужно создать контроллер для обработки входящего запроса. Класс CommerceControllerActivator реализует этот интерфейс и внутри себя собирает весь граф: репозиторий, адаптер пользователя, сервис — и отдает готовый контроллер фреймворку. Идея та же самая, что и в консольном методе Main, просто сборка происходит на каждый запрос, а не один раз при запуске.

Получите больше: Краткое содержание «Внедрение зависимостей в .NET»

Получайте новые идеи каждый день из более чем 100 000 уроков
Слова подсвечиваются синхронно с аудио
Ваша библиотека сохранена на всех устройствах

Глава 5

Внедрение через конструктор и ловушки, похожие на него

Итак, мы выделили корень композиции как единственное место, где создаются объекты. Возникает следующий вопрос: а как сами компоненты должны просить то, что им нужно? Симан отвечает: есть основной и самый предпочтительный способ, и использовать нужно почти всегда именно его. Это внедрение через конструктор. Класс, которому нужна изменчивая зависимость, просто объявляет ее как параметр в своем конструкторе. Вот и весь механизм. Конструктор ProductService принимает IProductRepository и IUserContext. Внутри класса эти зависимости просто уже есть — полностью готовые к работе. И класс никогда не думает о том, откуда они взялись. Правило Симана строгое: у класса должен быть один конструктор, и каждая действительно необходимая зависимость должна быть в нем объявлена. Существует также внедрение через метод — оно применяется, когда зависимость меняется от вызова к вызову, а не живет вместе с объектом. Есть и внедрение через свойство, но его область очень узкая: необязательные зависимости в переиспользуемых библиотеках, где есть разумное поведение по умолчанию. Но именно внедрение через конструктор — главный рабочий инструмент. Он делает требования класса очевидными. Вы физически не сможете создать объект, не передав ему всё необходимое. Очень поучительно посмотреть, где здесь совершают ошибки. Симан уделяет много времени сбоям и ловушкам, потому что они выглядят весьма соблазнительно. Первую ловушку он называет «маньяк контроля». Это ситуация, когда изменчивая зависимость создается через new где-либо за пределами корня композиции. Это та же самая базовая ошибка, просто в другой обертке. Создается ли объект прямо в конструкторе, в фабричном методе или в статическом помощнике — неважно. Как только класс сам создает свою изменчивую зависимость вместо того, чтобы получить ее снаружи, он намертво привязывается к конкретной реализации. И все плюсы — тестируемость, взаимозаменяемость, параллельная разработка — мгновенно испаряются. Вторая ловушка еще коварнее. Симан считает ее даже более опасной, потому что она маскируется под правильный подход. Это Сервис-локатор. Вместо создания зависимости напрямую, класс хранит ссылку на некий универсальный контейнер и во время работы просит у него: «Дай мне IProductRepository». Внешне это похоже на внедрение зависимостей. Есть интерфейс, есть гибкость. Но присмотритесь: зависимость класса от репозитория теперь спрятана глубоко внутри методов, а не объявлена в конструкторе. Глядя на сигнатуру конструктора, никто не сможет понять, что вообще нужно этому классу для работы. Тесты писать становится сложнее: вам приходится настраивать целый локатор и наполнять его объектами, даже если для конкретного теста они не нужны. Симан честно говорит: в эту ловушку легко попасть, потому что Сервис-локатор действительно полезен, но только в одном-единственном месте — внутри самого DI-контейнера на самом краю корня композиции. А вот использовать его вместо внедрения через конструктор по всему коду приложения — это серьезный антипаттерн. Есть и похожая ловушка под названием глобальный контекст. Это статическая, доступная отовсюду зависимость — вроде глобального ITimeProvider или статического логгера, к которому любой код может тихонько обратиться. Стивен ван Дёрсен описывает реальный случай, когда статическая библиотека логирования причинила много боли именно по этой причине. Зависимость была невидимой и нетестируемой, создавая скрытую связанность по всему проекту. И приводила к неприятному эффекту под названием временна́я связанность — когда код работает правильно только в том случае, если перед ним где-то в другом месте уже был тихо выполнен определенный шаг настройки. Суть всех этих ловушек одна: утаивание реальных зависимостей класса всегда обходится дорого в будущем, даже если прямо сейчас это кажется удобным экономичным решением.

Глава 6

Что вообще значит «жизнь» объекта

Когда зависимости начинают поступать через конструкторы из корня композиции, возникает новый вопрос. И Симан говорит, что на нем спотыкаются чаще всего: сколько именно должен жить объект? Здесь появляется понятие жизненного цикла объекта. Давайте опишем его максимально просто, потому что слово «жизненный цикл» звучит абстрактно, хотя суть у него вполне сугубо техническая. Каждый созданный объект существует определенное время: от момента вызова конструктора до сборки мусора или явного уничтожения. В плотно связанном приложении это время получается случайным — оно зависит от того, где именно вызвали оператор new. В правильно собранном приложении корень композиции полностью управляет этим процессом. И это решение невероятно важно. Ошибка здесь приводит к сложнейшим багам: утечке данных между независимыми запросами, неправильному использованию подключений к базе данных или падениям под нагрузкой в продакшне. Симан выделяет три основных стратегии управления жизненным циклом. Их стоит рассматривать вместе, потому что они понятны именно в сравнении друг с другом. Первая — Синглтон. Один единственный экземпляр, который создается один раз и используется всё время работы приложения. Представьте один общий водонагреватель на весь дом. Все квартиры берут воду из него. Это эффективно, но безопасно только тогда, когда объект готов к одновременной работе с разными клиентами — то, что программисты называют потокобезопасностью. Пример Симана — репозиторий товаров в оперативной памяти. Когда один общий объект хранит данные в памяти весь период работы приложения, это логично: данные одни, и все должны видеть одно и то же. Вторая стратегия — Транзиентный жизненный цикл. Новый экземпляр создается абсолютно каждый раз, когда кто-то о нем просит. Представьте одноразовый стаканчик для кофе. Вы не моете его для следующего покупателя, а выбрасываете и берете новый из стопки. Это самый безопасный вариант в плане утечек данных между частями программы. Но он менее эффективен по ресурсам, так как объекты создаются постоянно. И если объект требует явного освобождения ресурсов, этим процессом придется управлять вручную.

Следите за каждым словом во время прослушивания

Глава 7

Жизненный цикл, в котором путаются все

Третья стратегия — скоупед жизненный цикл. Именно она вызывает больше всего путаницы, поэтому давайте разберем ее подробно и на наглядном примере. Вот самое простое определение: скоупед-объект создается один раз и используется повторно, но только в рамках одной конкретной задачи или бизнес-операции. А потом уничтожается. Не навсегда, как синглтон. И не на каждый чих, как транзиентный объект. Он живет строго на время выполнения одной операции. Аналогия для понимания: представьте визит в ресторан за конкретный столик. Когда гости садятся, за ними закрепляют одного официанта на все время обеда — от закусок до desserts. Этот официант принимает все заказы этого столика, приносит напитки и счёт. Выделять нового официанта на каждый принос блюда было бы абсурдом — это транзиентный подход, доведенный до крайности. Но и заставлять одного официанта обслуживать вообще все столики в ресторане одновременно весь вечер — тоже нонсенс. Это синглтон, от которого требуют невозможного, и он либо запутается, либо унесет ваш заказ на соседний стол. Вместо этого ресторан создает привязку официанта к столику на время одного визита, использует ее весь обед, а когда гости платят и уходят — закрывает её. Для следующих гостей за этим столиком будет создана новая привязка. Для Симана главный пример скоупед-объекта — это DbContext в Entity Framework Core, который представляет собой активное соединение и единицу работы с базой данных. Внутри одного веб-запроса вы хотите, чтобы весь ваш код работал с одним и тем же экземпляром DbContext. Ведь он отслеживает изменения, и если разные части обработки одного запроса получат разные экземпляры, они не увидят изменений друг друга. К тому же вы откроете лишние подключения к базе. Но вы категорически не хотите, чтобы этот же DbContext достался следующему веб-запросу от другого пользователя! Иначе данные одного человека утекут к другому. Сам веб-запрос и является той самой рамкой, то есть скоупом. Один экземпляр создается на время запроса, используется всеми компонентами и уничтожается после отправки ответа. Симан показывает это на примере небольшого консольного приложения CurrencyMonitoring. Там нет веб-фреймворков, поэтому механизм скоупа виден в чистом виде. Класс Composer отвечает за управление CommerceContext. Вместо того чтобы делать DbContext синглтоном или пересоздавать его на каждый вызов, Composer явно открывает скоуп — ограниченный отрезок работы. Внутри него выполняется пакет операций с одним экземпляром CommerceContext, а затем скоуп закрывается. На следующем витке мониторинга открывается новый скоуп с новым CommerceContext. Жизненный цикл привязан не ко всему приложению и не к микро-операции, а к целому логическому блоку работы. Вот почему ошибка со скоупед-объектами приводит к одной из самых коварных проблем — пленённой зависимости. Это происходит, когда долгоживущий объект — например, синглтон — сохраняет ссылку на короткоживущий скоупед-объект, тот самый DbContext. Поскольку синглтон создается всего один раз, он захватывает тот скоупед-экземпляр, который существовал в момент его создания, и держит его вечно. Синглтон становится «тюремщиком». Скоупед-объект давно должен был уничтожиться, но он остаётся пленником. В итоге старый контекст базы данных начинает вечно переиспользоваться между чужими запросами. Решение Симана в чистом DI — это дисциплина структуры. Собирайте синглтоны на этапе старта приложения, а всё скоупед или транзиентное создавайте позже, строго внутри конкретных блоков работы. Никогда не позволяйте долгоживущему объекту захватывать короткоживущий. Есть и вторая форма этой ошибки — протекающая абстракция, когда деталь жизненного цикла вылезает наружу. Например, вы заворачиваете зависимость в `Lazy<T>`, чтобы отложить ее создание. Но это решение протекает наружу, заставляя весь внешний код знать о ленивой инициализации. Решение Симана — использовать виртуальный прокси. Это объект-заглушка с точно таким же интерфейсом, как и реальный сервис. Он сам незаметно создаст реальный объект ровно в момент первого обращения, и внешнему коду не придется знать ни о каких задержках. Похожая проблема бывает и при попытке привязать объект к текущему потоку: современный асинхронный код легко меняет потоки во время выполнения, и привязка к потоку ломается. Правильный путь — привязывать объект к реальной бизнес-операции или запросу, а не к техническим деталям вроде потоков. Запомните простую аналогию с рестораном: синглтон — это единственный водонагреватель на весь дом, транзиентный объект — одноразовый стаканчик, а скоупед — официант, закрепленный за вашим столиком строго на время вашего обеда.

Глава 8

Скоупед жизненный цикл: объясняем на пальцах

Два простых жизненных цикла мы уже разбрали. Транзиентный объект — одноразовый, он создается заново по каждому требованию. Синглтон — постоянный, создается один раз на всё время работы приложения. Скоупед находится ровно посередине. И именно в нем чаще всего путаются, потому что он определяется не временем, а границами. Подумайте о скоупед-объекте как об одном визите в ресторан. Официант работает с вашим столиком от момента, как вы сели, и до оплаты чека. Все блюда и просьбы принести воды идут через него. Но как только вы уходите, он начинает обслуживать других. Завтра он вас даже не вспомнит. Это и есть скоупед: один экземпляр, который используется внутри одной четко очерченной операции — чаще всего одного веб-запроса — и выбрасывается сразу по ее завершении. Представьте веб-запрос. Ему нужно подключение к базе данных через репозиторий. При скоупед-цикле репозиторий создается ровно один раз для этого запроса. Если три разных класса в цепочке — сервис товаров, калькулятор цен и валидатор заказов — попросят этот репозиторий, они получат один и тот же экземпляр. Потому что все они находятся за одним столиком, в рамках одного обеда. Как только ответ уходит в браузер, объект выбрасывается. Следующий запрос получит уже своего официанта и свой репозиторий. Почему это так важно? Потому что подключение к базе данных ведет себя совершенно по-разному в зависимости от времени жизни. Если делиться им правильно внутри одного запроса — всё работает согласованно. Если ошибиться — вы получите ту самую проблему, о которой мы поговорим прямо сейчас.

Получите больше: Краткое содержание «Внедрение зависимостей в .NET»

Получайте новые идеи каждый день из более чем 100 000 уроков
Слова подсвечиваются синхронно с аудио
Ваша библиотека сохранена на всех устройствах

Глава 9

Ловушка пленённой зависимости

Пленённая зависимость — это термин, который стоит запомнить. Увидев эту ошибку один раз, вы будете узнавать ее повсюду. Она возникает тогда, когда временный объект оказывается заперт внутри вечного. Представьте снова нашего официанта. А теперь вообразите, что хозяин ресторана, который находится там круглосуточно, решил сделать этого конкретного официанта своим личным бессменным ассистентом. Официант больше не уходит со смены. Он навечно привязан к человеку, который никогда не покидает здание. В коде происходит то же самое: сервис-синглтон, созданный один раз на всё время работы программы, просит скоупед-репозиторий в своем конструкторе. Он получает его в момент сборки и сохраняет ссылку навсегда. Ведь синглтон создается только один раз! Репозиторий, который должен был обновляться на каждый запрос, оказывается пойман и заперт. Эта ошибка не вылезет при обычном ручном тестировании. Она проявится под нагрузкой, через три недели, когда два параллельных веб-запроса одновременно обратятся к одному и тому же плененному репозиторию и одной базе данных. Данные начнут искажаться, потоки будут мешать друг другу, а отследить такой баг крайне сложно, ведь по отдельности каждый класс выглядит абсолютно правильно. Выход из этой ситуации — простое правило приоритета жизненных циклов: компонент никогда не должен жить дольше, чем зависимости, от которых он зависит. Синглтон может безопасно зависеть только от других синглтонов. Скоупед-объект может зависеть от скоупед-объектов или синглтонов. А транзиентный объект может зависеть от чего угодно — он всё равно исчезнет слишком быстро, чтобы кого-то пленить. Если помнить это правило, пленённые зависимости перестанут быть загадкой, и вы сможете находить их с первого взгляда.

Глава 10

Собираем корень композиции вручную

Все эти задачи — управление жизненным циклом, защита от пленения зависимостей — должны решаться в конкретном месте. Это корень композиции: единственная точка, расположенная максимально близко к старту приложения, где собирается весь граф объектов. Давайте посмотрим, как это выглядит без использования сторонних контейнеров — такой подход называют «чистым DI». Чистый DI означает, что вы пишете весь код связывания вручную. Это выглядит до смешного просто и даже немного топорно: репозиторий создается, заворачивается в декоратор, передается в сервис, сервис передается в контроллер — и всё это в одном блоке обычного кода. Никакой магии, никаких конфигурационных файлов или сканирования сборок. Вы просто явным образом прописываете, что от чего зависит, в единственном разрешенном для этого месте. Все остальные классы приложения просто получают готовые зависимости через конструкторы и даже не догадываются, как они были созданы. Только корень композиции видит всю картину целиком. Зачем вообще собирать приложение вручную, если можно доверить это фреймворку? Потому что при чистом DI всё контролирует компилятор. Переименуйте интерфейс — и все места его создания тут же подсветятся красным. Вы не получите неприятных сюрпризов в продакшне через месяц из-за того, что контейнер не смог что-то сопоставить во время работы. Для большинства приложений этого более чем достаточно, и это отличная отправная точка. Но системы растут. Когда у вас сотни сервисов со сложными жизненными циклами и условными заменами, ручная сборка становится громоздкой. И вот тогда наступает момент взять DI-контейнер — например, Autofac, Simple Injector или встроенный Microsoft.Extensions.DependencyInjection в ASP.NET Core. Контейнер не меняет саму архитектуру. Он просто автоматизирует ту работу, которую корень композиции раньше делал вручную: собирает граф, учитывает жизненные циклы и отдает готовый объект.

Следите за каждым словом во время прослушивания

Глава 11

Декораторы: расширяем возможности, не трогая ядро

Граф собран, жизненные циклы настроены. И вот теперь архитектура начинает приносить реальную пользу. Представьте, что вам нужно добавить логирование на каждый вызов репозитория. Или добавить паттерн предохранитель, чтобы не нагружать сервис, который временно недоступен. Самый простой соблазн — открыть рабочий класс и написать этот код прямо там. Не делайте этого! Это именно та связанность, от которой мы пытались уйти. Вместо этого вы создаете второй класс. Он реализует точно такой же интерфейс, как и основной, и содержит его внутри себя. Представьте конверт, в который вложили письмо. Конверт добавляет марку, адрес и штемпель, но сам текст письма внутри остается нетронутым. Декоратор логирования вокруг репозитория делает то же самое: он реализует тот же интерфейс, поэтому внешне неотличим от оригинала. Но до и после вызова реального репозитория он делает запись в лог. При этом сам класс репозитория вообще ничего не знает про логирование и не подключает никаких библиотек. Он просто делает свою работу. Предохранитель работает аналогично. Вы заворачиваете отправку сообщений в декоратор, который считает ошибки. Если ошибок слишком много, он просто перестает делать вызовы и сразу возвращает сбой, защищая остальную систему. А основной класс отправки сообщений даже не содержит кода подсчета ошибок. Ему это знать не нужно. И поскольку каждый такой слой — это просто еще одна реализация того же интерфейса, вы можете собирать их как матрешку. Декоратор авторизации обворачивает декоратор логирования, а тот обворачивает реальный обработчик. Три слоя, и ни один не знает про существование других. Чтобы добавить новую сквозную функциональность или убрать старую, вам достаточно изменить одну строчку в корне композиции. Вам не придется трогать ни один класс с бизнес-логикой. Вот ради чего всё это делалось: внедрение через конструктор, единый корень композиции и дисциплина вокруг оператора new. Это не просто формальность. Это то, что дает вам возможность легко и чисто расширять систему.

Глава 12

Что это дает в долгосрочной перспективе

Каждое правило здесь сводится к одной простой мысли: вещи, которые меняются по разным причинам, не должны быть спаяны друг с другом. Библиотека работы с базой данных, логирование, предохранитель, правила расчета стоимости товара — ничто из этого не должно перемешиваться в одном месте. Держите их отдельно, и каждый элемент можно будет изменять, тестировать, менять на другой или чинить независимо от остальных. В этом и заключается главная награда. И вы вряд ли оцените ее в день написания кода. Вы оцените ее позже. Когда начинающему разработчику потребуется поменять базу данных, добавить флаг фичи или отследить баг по логам — и он обнаружит, что может сделать это, изменив один декоратор в одном месте, абсолютно не рискуя сломать всю остальную систему. Холодильнику на вашей кухне всё равно, кто произвел молоко на его полке. Вашему коду, построенному по этим принципам, точно так же всё равно, кто и как создал его зависимости. И это не просто абстрактная красота архитектуры. Это грань, отделяющая проект, с которым приятно работать годами, от кода, к которому боятся даже прикоснуться.

★★★★★

Вы дочитали Краткое содержание «Внедрение зависимостей в .NET» до конца

“Прошло 23 дня, и я пользуюсь приложением каждый день. Теперь оно стало частью моей повседневной жизни.”

jayallen

Ключевые темы: Краткое содержание «Внедрение зависимостей в .NET»

loose coupling
software maintainability
design pattern implementation
object composition
architectural seams

Лучшие цитаты — Краткое содержание «Внедрение зависимостей в .NET»

DI represents a fundamental shift in how we approach software design.
The fundamental purpose of DI is to write maintainable code.
Loose coupling through DI provides five key benefits.
Requirements inevitably change.
Over-abstraction can lead to unnecessary complexity.

Персонажи: Краткое содержание «Внедрение зависимостей в .NET»

Mark SeemannAuthor and expert on software architecture

Об авторе

Марк Симан, признанный автор книги Внедрение зависимостей в .NET и ведущий эксперт в области архитектуры программного обеспечения, сочетает в себе десятилетия практического опыта разработки с упором на устойчивые методы написания кода. Будучи сооснователем CloudCall Group Plc и обладателем патентов в области телекоммуникаций, он связывает теоретические концепции с реальными корпоративными приложениями. Его работа акцентирует внимание на чистом коде, поддерживаемости и парадигмах функционального программирования — темах, ставших центральными в его удостоенном награды Jolt Award руководстве по внедрению зависимостей и сопутствующей книге Внедрение зависимостей: принципы, практики, паттерны.

Помимо писательской деятельности, Симан делится опытом через свой популярный блог ploeh, курсы на Pluralsight и выступления на международных конференциях, таких как NDC London. Его идеи освещались на BBC News и CNBC, а разработанные им архитектурные решения влияют на разработчиков в организациях по всему миру.

Имея за плечами более 15 лет создания контента и более 100 технических докладов, он продолжает формировать современные практики разработки ПО. Книга Внедрение зависимостей в .NET остается фундаментальным трудом, переведенным на множество языков и используемым в программах профессионального обучения по всему миру.

Скачать резюме книги «Внедрение зависимостей в .NET»

Получите резюме книги «Внедрение зависимостей в .NET» в формате PDF или EPUB бесплатно. Распечатайте или читайте офлайн в любое время.

Пользователям также понравилось

Dependency injection in .NET

Mark Seemann

Обложка книги The Pragmatic Programmer: Lessons for Modern Developers

23 sources

The Pragmatic Programmer: Lessons for Modern Developers

Обложка книги Senior C# Vocabulary and the Systems That Survive

Design Patterns in C#: Which Ones Still Matter in 2026 | by Kerim Kara | Medium

Clean Architecture in C#: Practical Guide for .NET

.NET Architecture at Scale: Visual Guide to Modern Design Patterns | Nitin Singh | Enterprise AI & Architecture

6 sources

Senior C# Vocabulary and the Systems That Survive

Обложка книги O Programador Pragmático: Lições de Maestria

Becoming a Pragmatic Programmer: 101 Quick Key Takeaways from "The Pragmatic Programmer" 20th Anniversary Edition
| MikeTsamis.com

The Pragmatic Programmer - Book Summary - TheScrumMaster.co.uk

O Programador Pragmático - Resumo do Livro - TheScrumMaster.co.uk

5 conclusões essenciais de “The Pragmatic Programmer”

4 sources

O Programador Pragmático: Lições de Maestria

Обложка книги Codependency Detox: From People-Pleasing to Powerful Boundaries

30 sources

Codependency Detox: From People-Pleasing to Powerful Boundaries

Writing High-Performance .NET Code

Ben Watson

Обложка книги Rapid Landing Pages in Visual Studio

Create C# ASP.NET Core web application - Visual Studio (Windows)

Net Core 10: ASP.Net Razor Pages Hello World Tutorial [2026]

Tutorial: Get started with Razor Pages in ASP.NET Core

9 sources

Rapid Landing Pages in Visual Studio

Обложка книги Software Engineering Deep Dive: Timeless Wisdom

7 sources

Software Engineering Deep Dive: Timeless Wisdom

Частые вопросы про Краткое содержание «Внедрение зависимостей в .NET»

Узнать больше

ПЛАН ОБУЧЕНИЯ

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 Разделы

ПЛАН ОБУЧЕНИЯ

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 Разделы

ПЛАН ОБУЧЕНИЯ

DevSecOps

As cyber threats evolve, security can no longer be a final checkpoint; it must be embedded into every stage of the software lifecycle. This plan is essential for developers, DevOps engineers, and security professionals looking to build resilient, automated, and compliant delivery pipelines.

5 h 2 m•4 Разделы

ПЛАН ОБУЧЕНИЯ

Programming

This comprehensive path bridges the gap between basic syntax and professional system architecture. It is ideal for aspiring developers who want to master both the practical skills of coding and the high-level design patterns used in top-tier tech companies.

5 h 1 m•4 Разделы

ПЛАН ОБУЧЕНИЯ

From Zero to Coder

This comprehensive path bridges the gap between digital literacy and professional software development. It is ideal for absolute beginners who want to move beyond basic syntax to building functional web applications with industry-standard tools.

2 h•5 Разделы

ПЛАН ОБУЧЕНИЯ

Learn software dev

This comprehensive learning path takes you from programming beginner to professional software engineer, covering everything from writing your first line of code to making architectural decisions for large-scale systems. It's ideal for career changers entering tech, self-taught programmers looking to formalize their skills, or junior developers aiming to reach senior-level expertise. The structured progression ensures you build both technical proficiency and the professional mindset needed to succeed in modern software development teams.

4 h 50 m•4 Разделы

ПЛАН ОБУЧЕНИЯ

Build Atomic JSON:API in .NET

This plan is essential for .NET developers building high-performance, standardized APIs that require complex data handling. It benefits backend engineers looking to implement the JSON:API spec and its powerful atomic operations extension for transactional consistency.

1 h 15 m•3 Разделы

ПЛАН ОБУЧЕНИЯ

Advanced Azure Development and AI Integration

This learning plan bridges the gap between traditional development and modern cloud-native approaches for technical professionals seeking to enhance their Azure expertise. It's ideal for consultants and developers who need to deliver enterprise-grade solutions while leveraging Microsoft's full technology stack including containers, low-code platforms, and AI services.

4 h 9 m•4 Разделы

Создано выпускниками Колумбийского университета | в Сан-Франциско

BeFreed объединяет глобальное сообщество любознательных людей

4.7

средняя оценка

Более 7,84 тыс. оценок приложения

Сообщество BeFreed

Честно говоря, я ещё даже не изучила приложение полностью, но за последние несколько дней оно меня по-настоящему впечатлило… BeFreed — совсем другой уровень по сравнению с любыми учебными приложениями, которыми я пользовалась. Оно невероятно увлекает и действительно улучшает концентрацию — то, что нужно всем, кто бесконечно листает ленту!

@ladyInfinity

Я купил BeFreed ровно 23 дня назад и с тех пор пользуюсь им каждый день. Оно полностью встроилось в мой рабочий процесс и привычку учиться.

@jayallen

Честно говоря, приложение превзошло все мои ожидания. Я могу попросить его сгенерировать аудио на любую тему, какой бы она ни была, и результат впечатляет. Моя профессиональная область — специализация в психотерапии, она мультидисциплинарная, но ответы очень точные.

@Raguipa

Больше всего я ценю то, насколько меньше я стал листать ленту: меньше времени уходит на поиск и больше — на усвоение информации. Сочетание полных аудиокниг, подкастов и планов обучения — блестящее.

@colonyofcreatorsNGO

Я уже 24 года работаю инструктором ускоренного обучения PhotoReading… книги, чтение и обучение — моя стихия, и BeFreed отлично справился, предложив инновационный подход к подаче информации в лёгкой для восприятия форме.

@BeFreed user

Это не просто приложение с кратким содержанием книг: я попробовал режим «весёлого чтения», и это гораздо лучший пересказ и способ схватывать идеи, чем традиционный. Уже ради одного этого оно того стоит.

@austinakon

Обожаю это приложение. Пользуюсь несколько дней и не могу перестать слушать. Отличный способ начать.

@jcrules328

Мне очень нравится это приложение; я тестирую его уже около месяца и считаю настоящей находкой. Оно отлично работает, потому что в BeFreed можно создавать собственные темы, а голос замечательный — с безграничным выбором озвучек.

@DanielCZ

Честно говоря, я ещё даже не изучила приложение полностью, но за последние несколько дней оно меня по-настоящему впечатлило… BeFreed — совсем другой уровень по сравнению с любыми учебными приложениями, которыми я пользовалась. Оно невероятно увлекает и действительно улучшает концентрацию — то, что нужно всем, кто бесконечно листает ленту!

@ladyInfinity

Я купил BeFreed ровно 23 дня назад и с тех пор пользуюсь им каждый день. Оно полностью встроилось в мой рабочий процесс и привычку учиться.

@jayallen

Честно говоря, приложение превзошло все мои ожидания. Я могу попросить его сгенерировать аудио на любую тему, какой бы она ни была, и результат впечатляет. Моя профессиональная область — специализация в психотерапии, она мультидисциплинарная, но ответы очень точные.

@Raguipa

Больше всего я ценю то, насколько меньше я стал листать ленту: меньше времени уходит на поиск и больше — на усвоение информации. Сочетание полных аудиокниг, подкастов и планов обучения — блестящее.

@colonyofcreatorsNGO

Я уже 24 года работаю инструктором ускоренного обучения PhotoReading… книги, чтение и обучение — моя стихия, и BeFreed отлично справился, предложив инновационный подход к подаче информации в лёгкой для восприятия форме.

@BeFreed user

Это не просто приложение с кратким содержанием книг: я попробовал режим «весёлого чтения», и это гораздо лучший пересказ и способ схватывать идеи, чем традиционный. Уже ради одного этого оно того стоит.

@austinakon

Обожаю это приложение. Пользуюсь несколько дней и не могу перестать слушать. Отличный способ начать.

@jcrules328

Мне очень нравится это приложение; я тестирую его уже около месяца и считаю настоящей находкой. Оно отлично работает, потому что в BeFreed можно создавать собственные темы, а голос замечательный — с безграничным выбором озвучек.

@DanielCZ

Мне очень нравится, что полезную, сжатую информацию и идеи можно получить в виде аудио в стиле подкаста на 8–15 минут. Я не большой фанат подкастов из-за «воды», но здесь её нет совсем.

@BeFreed user

Я заканчиваю докторскую и вынужден читать много незнакомого материала… В BeFreed достаточно ввести запрос — приложение само находит источники и создаёт аудиоподкаст. Мне процесс в BeFreed кажется удобнее, чем в NotebookLM.

@Brad

Я часто ищу на YouTube, что послушать за завтраком, на прогулке или по дороге на работу, и BeFreed предлагает ещё более точный подход — без рекламы и без «воды»!

@BeFreed user

Самое лучшее в этой платформе — её универсальность. Нет буквально ни одной темы, которая была бы ей не по зубам. Она справляется со всем, что ей даёшь… Редко встретишь учебный инструмент без ограничений, который действительно выполняет обещания.

@jayallen

BeFreed — потрясающее приложение. Благодаря удобному дизайну я трачу меньше времени на навигацию и больше — на учёбу. Сочетание аудиокниг, подкастов и планов обучения — гениальная комбинация, которая полностью изменила мой распорядок дня.

@BeFreed user

Сначала мне понадобилось время, чтобы разобраться, как создавать подкасты на итальянском, а потом — бум! Это же великолепно! Можно попросить объяснить любую тему, и он делает это отлично и очень умно!

@matteo77

BeFreed стал моим ежедневным приложением для аудиокниг… Больше всего мне нравится, что ты вставляешь свой текст — и получаешь аудио, которое можно слушать на ходу.

@kotanzu1

Мне очень нравится, что полезную, сжатую информацию и идеи можно получить в виде аудио в стиле подкаста на 8–15 минут. Я не большой фанат подкастов из-за «воды», но здесь её нет совсем.

@BeFreed user

Я заканчиваю докторскую и вынужден читать много незнакомого материала… В BeFreed достаточно ввести запрос — приложение само находит источники и создаёт аудиоподкаст. Мне процесс в BeFreed кажется удобнее, чем в NotebookLM.

@Brad

Я часто ищу на YouTube, что послушать за завтраком, на прогулке или по дороге на работу, и BeFreed предлагает ещё более точный подход — без рекламы и без «воды»!

@BeFreed user

Самое лучшее в этой платформе — её универсальность. Нет буквально ни одной темы, которая была бы ей не по зубам. Она справляется со всем, что ей даёшь… Редко встретишь учебный инструмент без ограничений, который действительно выполняет обещания.

@jayallen

BeFreed — потрясающее приложение. Благодаря удобному дизайну я трачу меньше времени на навигацию и больше — на учёбу. Сочетание аудиокниг, подкастов и планов обучения — гениальная комбинация, которая полностью изменила мой распорядок дня.

@BeFreed user

Сначала мне понадобилось время, чтобы разобраться, как создавать подкасты на итальянском, а потом — бум! Это же великолепно! Можно попросить объяснить любую тему, и он делает это отлично и очень умно!

@matteo77

BeFreed стал моим ежедневным приложением для аудиокниг… Больше всего мне нравится, что ты вставляешь свой текст — и получаешь аудио, которое можно слушать на ходу.

@kotanzu1

Узнайте больше о том, как обсуждают BeFreed в интернете