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.

Injeção de Dependência em .NET book cover

Resumo de Injeção de Dependência em .NET

Mark Seemann

4.43(777 Reviews)

Visão geral do Resumo de Injeção de Dependência em .NET

Revolucione seu código C# com "Dependency Injection in .NET" - o guia seminal de Mark Seemann que transformou a maneira como os desenvolvedores abordam os princípios SOLID. O livro que tornou o acoplamento fraco algo "cool" antes mesmo dos microsserviços se tornarem populares.

Escolha como a história é contada

Explore o Resumo de Injeção de Dependência em .NET em diferentes estilos de aprendizagem

As mesmas ideias de Injeção de Dependência em .NET. Escolha a voz, a profundidade e o ritmo ideais para você. Mude quando quiser.

Capítulo 1

A Geladeira na Sua Cozinha

Vou começar com uma ideia que parece estranha de início: o conceito mais importante na arquitetura de software profissional é exatamente o mesmo motivo pelo qual a sua geladeira tem um plugue e não um fio soldado direto na parede. O Mark Seemann passou anos observando desenvolvedores escreverem códigos que funcionavam perfeitamente no dia do lançamento, mas que depois ficavam quase impossíveis de mexer. E não porque a lógica estava errada. Era porque tudo estava conectado diretamente em tudo, do mesmo jeito que se construíam casas antigamente, com o fio da geladeira emendado direto na fiação atrás do gesso. Quer trocar de geladeira? Tem que chamar um eletricista. Quer mudeá-la de lugar? Vai ter que quebrar a parede. Aí alguém inventou a tomada. A tomada não quer saber qual é a marca da sua geladeira. Ela oferece um encaixe padrão, um formato fixo, uma promessa. Qualquer aparelho que sirva naquele formato pode ser ligado ali. E a geladeira não sabe nem se importa de onde vem a energia, se vem de uma usina hidrelétrica, de um painel solar ou de um gerador a diesel no porão. Ela só sabe que vai receber energia por aquele encaixe. Em essência, isso é a injeção de dependência. Não é uma ferramenta. Não é uma biblioteca que você instala. É uma postura arquitetural: construa seu software de forma que as partes que fazem o trabalho pesado nunca saiam buscando aquilo de que precisam. Em vez disso, essas dependências são entregues a elas, por um encaixe padrão, vindo de fora. O livro do Seemann, que ganhou o Prêmio Jolt e virou uma das maiores referências no assunto, defende que esse único hábito, mantido com consistência, é o que separa um sistema que você consegue evoluir de um código que petrifica. E por que isso importa além dos termos técnicos? O Seemann faz questão de dizer que a injeção de dependência é incompreendida o tempo todo. Tem gente que acha que é só um jeito chique de fazer vinculação tardia. Não é. Acham que só serve para testes unitários. Ela ajuda nisso, mas é um efeito colateral, não o objetivo principal. Acham que você precisa obrigatoriamente de um container de injeção de dependência, aquele framework esperto que conecta os objetos automaticamente. Não precisa. Você pode fazer tudo isso à mão, o que ele chama de Injeção de Dependência Pura, e vários sistemas grandes e sérios fazem exatamente assim. E ainda confundem isso com o Localizador de Serviços, que por fora parece similar, mas, como vamos ver, é na verdade o oposto dessa disciplina. O que vamos ver na próxima meia hora é como a engrenagem funciona na prática. Não é só dizer que "o acoplamento fraco é bom", mas como pegar uma aplicação emaranhada e virar do avesso, para que ela seja mantida por tomadas em vez de fios soldados. Como fazer o tempo de vida de um objeto ser algo que você controla de propósito, e não por acidente. E como você pode encaixar coisas como logs, checagens de segurança e lógicas de repetição no seu código de negócio sem que ele sequer saiba que essas coisas existem. Vamos começar de onde o Seemann começa: com o tipo específico de dependência que realmente merece esse tratamento.

Capítulo 2

As Dependências com que Você Deve se Preocupar

Nem toda dependência em um software é um problema. Essa é a primeira coisa que precisamos alinhar. É fácil cair na tentação de achar que injeção de dependência significa colocar uma interface em absolutamente tudo e injetar tudo, o que é exaustivo e inútil. O Seemann faz uma divisão bem clara entre o que ele chama de dependências estáveis e dependências voláteis. Uma dependência estável é algo como uma classe da Biblioteca de Classes Base do .NET, uma string, uma lista, operações matemáticas básicas. Ela é determinística. Funciona sempre do mesmo jeito. Não vai sumir e você nunca vai precisar trocá-la por outra coisa. Não faz sentido nenhum injetar uma string. A dependência volátil é diferente. Ela é volátil se precisa de um ambiente configurado ao redor dela, como uma conexão com banco de dados, uma chamada de rede ou acesso ao sistema de arquivos. Ela é volátil se ainda nem existe, ou seja, quando você está escrevendo um código hoje para se conectar a uma parte do sistema que outra equipe ainda está desenvolvendo. E ela é volátil se tiver um comportamento não determinístico, fornecendo respostas diferentes dependendo da hora do dia, do estado de um sistema externo, de números aleatórios ou da data atual. Bancos de dados, serviços web, o relógio do sistema, geradores de números aleatórios. São essas as partes do código que o Seemann diz que merecem ser isoladas atrás de uma interface e entregues de fora, em vez de serem criadas diretamente onde são usadas. Essa distinção é fundamental porque mostra onde gastar energia. Você não precisa de um teatro de injeção de dependência em todo lugar. Você precisa disso exatamente nas fronteiras, nos pontos onde o seu aplicativo toca o mundo exterior, que é imprevisível. Para deixar isso bem concreto, o Seemann conta uma história. Uma desenvolvedora chamada Mary Rowan está criando um aplicativo de e-commerce, usando ASP.NET Core na camada web e Entity Framework Core para falar com o banco de dados, além de lógicas para calcular descontos e destacar produtos na página inicial. A primeira versão desse app, que o Seemann escreve mal de propósito, é um estudo de caso do que acontece quando você ignora totalmente a diferença entre o que é estável e o que é volátil. A classe de lógica de negócio da Mary, a ProductService, recebe um palpite de um colega chamado Jens. Ele sugere o caminho pragmático e óbvio: basta acessar diretamente o contexto do banco de dados, o CommerceContext, de dentro da regra de negócio. É só instanciar com um `new` ali mesmo. Para que complicar? Funciona, compila e roda. Só que agora a classe ProductService está soldada ao Entity Framework. O Seemann mostra o que acontece quando você tenta testar essa classe, ou trocar a camada de dados, ou trabalhar na interface gráfica enquanto outra pessoa mexe no banco. Você não consegue. Se desenharmos o gráfico de dependências com setas, a interface depende da regra de negócio, e a regra de negócio depende diretamente da camada de dados concreta. Se quiser trocar a interface, tudo bem, nada mais se importa. Mas se tentar trocar a camada de dados, o erro sobe cascateando pela lógica de negócio até chegar ao controlador. Uma mudança no fundo da estrutura força uma reescrita no topo. O diagnóstico do Seemann é direto: a causa raiz não é que o Entity Framework seja ruim, mas sim que a ProductService, uma lógica de negócio que deveria ser estável e abstrata, criou uma dependência forte com algo volátil. A solução não é um remendo. É a inversão.

Veja cada palavra enquanto a ouve

Acompanhe a leitura sem esforço enquanto cada palavra do Resumo de Injeção de Dependência em .NET se destaca em tempo real.

Capítulo 3

Invertendo a Fiação

Então aqui está o mecanismo real, aquela parte que muitas vezes as pessoas explicam por cima sem mostrar como faz: como pegar essa bagunça acoplada e invertê-la? A jogada se chama Princípio da Inversão de Dependência, e o truque parece quase uma mágica quando você entende. Em vez de a ProductService depender da classe concreta de acesso a dados, você define uma interface, a IProductRepository, que mora dentro da própria camada de domínio, bem ao lado da ProductService. Não dentro da camada de dados. Dentro do domínio. Essa é a parte que muita gente pula, e é o grande segredo. A camada de domínio define o formato do que ela precisa, nos termos dela, e a camada de dados é quem tem que ir até lá e implementar esse formato. Pense no que isso faz com as setas do diagrama. Antes, o domínio dependia dos dados. Agora, os dados dependem do domínio, porque a classe SqlProductRepository, que fica na camada de acesso a dados, implementa a IProductRepository, uma interface mantida pelo domínio. A direção da dependência se inverteu fisicamente, embora a direção das chamadas de método durante a execução continue exatamente a mesma. A ProductService continua pedindo produtos e recebendo os resultados. Mas no papel, em termos de quem depende de quem, o domínio agora é dono apenas de abstrações. E tudo o que é volátil — o banco de dados, o framework web — aponta para dentro, em direção ao domínio, e não o contrário. O Seemann reescreve todo o aplicativo da Mary usando essa ideia, trabalhando de fora para dentro. O controlador depende apenas da IProductService. A própria ProductService é construída recebendo uma IProductRepository e um IUserContext pelo seu construtor, sem ir atrás deles por conta própria. A classe concreta SqlProductRepository, que é quem toca no CommerceContext e no Entity Framework, mora inteiramente na camada de dados, implementando a interface definida pelo domínio. Há também um adaptador, o AspNetUserContextAdapter, que pega as informações de identidade do ASP.NET e as traduz para o formato que o IUserContext espera, para que o domínio nunca precise saber que o ASP.NET existe. Se você desenhar o gráfico de dependências depois dessa refatoração, algo incrível acontece: a camada de domínio não tem nenhuma dependência saindo dela. Nenhuma. Ela fica no centro, como pura lógica de negócio, e tanto a interface gráfica quanto a camada de dados apontam para ela, implementando suas interfaces. Você pode trocar o Entity Framework por qualquer outra tecnologia de banco de dados, e a ProductService nem percebe, nunca muda, nem precisa ser recompilada. É assim que a composibilidade se parece de verdade. Mas surge uma pergunta óbvia, e é exatamente a que o Seemann responde a seguir. Se a ProductService só pede uma IProductRepository no construtor e nunca cria uma por conta própria, alguém, em algum lugar, precisa criar a SqlProductRepository de verdade e entregá-la. Quem faz esse trabalho? É aqui que essa disciplina se sustenta ou cai por terra.

Capítulo 4

O Único Lugar Onde se Pode Usar o "New"

A resposta é um local único e bem delimitado na sua aplicação chamado Raiz de Composição. O Seemann a descreve como um lugar lógico, o mais perto possível do ponto de entrada da aplicação, onde todo o gráfico de objetos é montado. Toda dependência volátil é instanciada ali e repassada para os objetos que precisam dela. Em qualquer outro lugar do código, a regra é clara: nenhum objeto volátil pode ser criado com um `new` simples fora desse ponto. Isso soa, de início, como algo impossível. Se a ProductService precisa de um repositório, o repositório precisa de uma string de conexão, e a string precisa de configurações, isso não significa que a Raiz de Composição vai precisar saber sobre tudo no sistema inteiro? O Seemann chama isso de uma aparente "explosão de dependências" e explica por que isso é só uma ilusão. Não é que a Raiz de Composição precise entender dezenas de assuntos não relacionados. É uma questão de transitividade. Se A depende de B, e B depende de C, então alguém precisa fornecer o C para conseguir construir o A. Isso sempre foi verdade. A Raiz de Composição só deixa isso visível em vez de esconder em dezenas de `new` espalhados por vários construtores diferentes. Como isso funciona na prática? Imagine a versão do app da Mary para linha de comando, uma ferramenta simples de atualização de moedas. O ponto de entrada, o método Main, é a Raiz de Composição. Ele carrega as configurações primeiro: string de conexão, chave de API, o que o mundo externo exigir. Só depois ele começa a construir as coisas. Ele cria primeiro as peças voláteis de nível mais baixo, como um leitor de moedas conectado ao banco, depois envolve isso nos objetos do nível acima, e vai repassando as instâncias para cima até ter um gráfico de objetos completo e pronto para rodar. Aí ele chama um único método para colocar tudo em movimento. Nada nesse padrão depende de frameworks. São só construtores chamados na ordem certa, em um único arquivo, no momento em que a aplicação inicia. É só isso. É isso que as pessoas querem dizer com Injeção de Dependência Pura. Sem mágica, sem reflexão, sem container. Apenas a construção centralizada de objetos, mantida longe da lógica de negócio. A versão para ASP.NET Core funciona no mesmo princípio, mas se encaixa em um ponto de extensão específico, algo chamado IControllerActivator, que o framework chama toda vez que precisa criar um controlador para lidar com uma requisição. O CommerceControllerActivator da Mary implementa essa interface, e dentro dele monta o gráfico completo: o repositório, o adaptador de contexto de usuário, o serviço, e devolve o controlador pronto para o framework. É a mesma ideia do método Main da aplicação de console, só que executado a cada requisição em vez de uma única vez na inicialização.

Aproveite ainda mais o Resumo de Injeção de Dependência em .NET

Receba insights diários de mais de 100 mil lições
As palavras se destacam em sincronia com o áudio
Sua biblioteca salva em todos os dispositivos

Capítulo 5

Injeção por Construtor e as Armadilhas Parecidas

Com a Raiz de Composição definida como o único lugar autorizado a instanciar coisas, a pergunta seguinte é: como as peças pedem o que precisam? A resposta do Seemann é que existe um padrão principal e muito recomendado, que você deve usar quase sempre: a Injeção por Construtor. A classe que precisa de uma dependência volátil a declara como um parâmetro no seu construtor. Esse é todo o mecanismo. O construtor da ProductService recebe um IProductRepository e um IUserContext. Dentro da classe, essas dependências simplesmente existem, prontas para usar, e a classe nunca precisa pensar de onde elas vieram. A regra do Seemann é rígida: uma classe deve ter um único construtor, e todas as dependências realmente necessárias devem estar ali, sem serem opcionais. Existe também a Injeção por Método, reservada para casos em que a dependência varia a cada chamada em vez de ficar fixa durante toda a vida do objeto. E a Injeção por Propriedade, usada apenas para dependências opcionais em bibliotecas reutilizáveis, onde existe um comportamento padrão caso ninguém forneça nada. Mas a Injeção por Construtor é o padrão seguro, porque deixa as exigências da classe visíveis e impossíveis de esquecer. Você simplesmente não consegue construir o objeto sem fornecer o que ele precisa. Onde isso costuma dar errado? O Seemann dedica um bom tempo aos modos de falha porque eles são muito atraentes. O primeiro é o que ele chama de Control Freak: qualquer momento em que uma dependência volátil é criada com `new` fora da Raiz de Composição. É o erro original da Mary com outra roupagem. Pode não ser o construtor fazendo isso; pode ser um método fábrica ou uma classe utilitária estática. Não importa. No momento em que uma classe cria sua própria dependência volátil em vez de recebê-la, ela se solda a uma implementação específica, e todos os benefícios — facilidade de testes, substituição, desenvolvimento paralelo — somem. A segunda armadilha é mais sutil e até mais perigosa, porque parece uma escolha responsável: o Localizador de Serviços. Em vez de instanciar uma dependência diretamente, a classe guarda um objeto container genérico e pede a ele, em tempo de execução: "me dá um IProductRepository". Parece injeção de dependência. Tem interface, tem flexibilidade. Mas olhe de perto: a dependência da classe com aquela interface agora está escondida dentro dos métodos, em vez de declarada no construtor. Ninguém olhando para o construtor consegue saber do que a classe precisa para funcionar. Fazer testes fica mais difícil porque você precisa configurar um localizador inteiro com tudo o que a classe pode pedir, inclusive coisas que nem são usadas naquele teste específico. O Seemann é direto ao dizer que é fácil cair nessa armadilha porque ela é útil em exatamente um lugar: dentro do mecanismo interno do próprio Container de Injeção de Dependência, na borda da Raiz de Composição. O antipadrão é usá-la como substituto para a Injeção por Construtor no código comum da aplicação. Há uma armadilha relacionada chamada Contexto Ambiente, que é uma dependência estática e global, como um provedor de horário global ou um sistema de log estático, que qualquer parte do código pode acessar silenciosamente. O Steven van Deursen conta uma dificuldade real com uma biblioteca de log estática que causou dores de cabeça sérias justamente por isso: a dependência era invisível, impossível de testar e gerava um acoplamento oculto por todo o sistema, além de um efeito colateral desagradável chamado Acoplamento Temporal, onde o código só funciona se outra etapa invisível tiver acontecido antes, na ordem certa, em outro lugar. O ponto em comum entre todas essas armadilhas é o mesmo: esconder o que uma classe realmente precisa sempre cobra o seu preço mais tarde, mesmo que economize um segundo agora.

Capítulo 6

O que Significa um Objeto Estar "Vivo"

Quando as dependências começam a entrar pelos construtores a partir de uma Raiz de Composição bem definida, surge uma nova dúvida, que segundo o Seemann confunde mais do que quase qualquer outra coisa nessa área: quanto tempo um objeto deve durar? É aqui que entra o conceito de Tempo de Vida do Objeto. Vale a pena explicar isso de forma bem direta, porque a palavra "tempo de vida" faz parecer algo abstrato, quando na verdade é totalmente prático. Todo objeto que você cria existe por um período entre o momento em que é construído e o momento em que é limpo pela memória. Em um app cheio de acoplamento, esse período é invisível e acidental, decidido onde quer que o `new` tenha sido chamado. Em um aplicativo bem estruturado, a Raiz de Composição — ou o Compositor, como o Seemann às vezes chama o componente responsável por gerenciar esse ciclo — toma essa decisão de propósito. E essa decisão importa muito, porque errar nisso gera bugs horríveis de encontrar: dados vazando entre requisições que deveriam ser isoladas, conexões com banco sendo compartilhadas de formas que corrompem o estado, ou falhas em produção quando o sistema recebe muita carga. O Seemann apresenta três estilos de vida principais para gerenciar esse ciclo. Vale a pena entender os três juntos, porque eles só fazem sentido quando comparados. O primeiro é o Singleton. Uma única instância, criada uma vez e reutilizada durante toda a vida da aplicação. Pense nele como o aquecedor de água central de um prédio. Todos os apartamentos usam o mesmo. Isso é muito eficiente, mas só funciona com segurança se a peça compartilhada puder ser usada por vários acessos ao mesmo tempo sem se confundir, o que os programadores chamam de segurança de threads. O exemplo do Seemann aqui é algo como um repositório de produtos em memória, onde manter uma única instância compartilhada faz sentido, já que só existe uma cópia dos dados e todos devem ver a mesma coisa. O segundo é o Transiente. Uma instância novinha em folha a cada pedido. Pense nele como um copo de papel descartável. Você não lava o copo para dar ao próximo cliente; você joga fora e pega um novo na pilha. Essa é a opção mais segura no sentido de que você nunca vai vazar dados entre partes diferentes do sistema, mas é a menos eficiente, já que você paga o custo da criação o tempo todo. E se o objeto precisar de limpeza ao ser descartado, você precisa gerenciar isso ativamente.

Veja cada palavra enquanto a ouve

Acompanhe a leitura sem esforço enquanto cada palavra do Resumo de Injeção de Dependência em .NET se destaca em tempo real.

Capítulo 7

O Tempo de Vida que Confunde Todo Mundo

O terceiro estilo de vida é o Escopado, e é esse que costuma dar nós na cabeça das pessoas. Por isso vale a pena explicar passo a passo. A forma mais simples de definir o que é "escopado" é: o objeto é criado uma vez e reutilizado, mas apenas durante a execução de uma unidade de trabalho específica, e depois desaparece. Não dura para sempre, como o Singleton. Nem dura só uma chamada de método, como o Transiente. Ele dura exatamente aquele período delimitado, e é descartado quando esse período acaba. Uma boa analogia: pense no escopo como o atendimento de uma mesa em um restaurante. Quando os clientes sentam, o restaurante atribui um garçom para atender essa mesa durante todo o jantar, da entrada à sobremesa. Aquele garçom atende a todos os pedidos daquela mesa, traz as bebidas, a conta no final. Seria absurdo trocar de garçom a cada prato servido; isso seria o estilo Transiente levado ao exagero. Também seria absurdo aquele único garçom atender todas as mesas do restaurante ao mesmo tempo a noite inteira; isso seria usar um Singleton para uma função que ele não aguenta, e o serviço quebraria com a lotação. Em vez disso, o restaurante cria uma relação entre garçom e mesa para aquele atendimento, usa essa relação durante a refeição, e a encerra assim que a mesa paga a conta e vai embora. Os próximos clientes naquela mesa terão um novo atendimento. O exemplo prático do Seemann para isso é o DbContext do Entity Framework Core, o objeto que representa a conexão ativa e a unidade de trabalho com o banco de dados. Em uma requisição web, você quer que todo o seu código que toca no banco compartilhe exatamente a mesma instância do DbContext, porque ele acompanha as alterações nos dados. Se duas partes da mesma requisição usassem instâncias separadas, uma poderia não ver as alterações da outra. Mas você definitivamente não quer que essa mesma instância continue ativa para a próxima requisição de outro usuário, porque isso vazaria dados e transações no meio do caminho. A requisição web é o escopo. Uma instância compartilhada enquanto a requisição durar, descartada assim que ela terminar. O Seemann demonstra isso com um pequeno exemplo de linha de comando chamado CurrencyMonitoring, feito sem frameworks web de propósito, só para mostrar a engrenagem do escopo funcionando de forma pura. Uma classe chamada Compositor é responsável por gerenciar o CommerceContext. Em vez de o DbContext ser um Singleton mantido o tempo todo, ou um Transiente recriado a todo momento, o Compositor define um escopo claro. Ele inicia o escopo, faz o lote de trabalho compartilhando a mesma instância do CommerceContext, e depois fecha o escopo. Na rodada seguinte, um novo escopo é criado, com um novo CommerceContext. O tempo de vida fica ligado a um bloco de trabalho bem definido. É por isso que errar na configuração do Escopado gera um dos piores bugs dessa área: a Dependência Cativa. Ela acontece quando um objeto de vida longa, como um Singleton, guarda uma referência para um objeto de vida curta, como um DbContext Escopado. Como o Singleton só é construído uma vez, ele pega a instância Escopada que existia naquele momento e a segura para sempre, muito depois de aquele escopo ter sido encerrado. O Singleton vira um prisioneiro daquela dependência, mantendo o objeto preso além do tempo correto. O resultado é um banco de dados desatualizado ou com conexões fechadas sendo reusado em requisições que não deveriam tocar nele. A solução do Seemann na Injeção de Dependência Pura é a disciplina de estrutura: monte seus Singletons na inicialização e crie tudo o que for Escopado ou Transiente depois, dentro de cada nova unidade de trabalho, sem deixar um objeto de vida longa prender um de vida curta. Há uma variação desse problema que o Seemann chama de Abstração Vazada revelando uma escolha de tempo de vida. Isso acontece, por exemplo, quando você usa `Lazy<T>` para adiar a criação de uma dependência, mas essa escolha vaza para fora, obrigando quem consome a classe a ter que lidar com essa lógica de adiamento. A solução dele é usar um Proxy Virtual, um objeto substituto que tem o mesmo formato da dependência real, mas que só cria o objeto de verdade por trás dos panos na hora em que ele for usado. Assim, ninguém mais precisa saber desse detalhe. Guarde a imagem do restaurante, porque ela é a melhor referência: Singleton é o aquecedor de água do prédio todo, Transiente é o copo descartável que você joga fora a cada uso, e Escopado é o garçom dedicado à sua mesa enquanto durar o seu jantar.

Capítulo 8

O Tempo de Vida Escopado, Sem Complicação

Você já entendeu os dois tempos de vida mais fáceis. O objeto transiente é descartável: precisou dele, cria-se um novo. O singleton é permanente: uma instância criada uma vez e usada durante toda a vida da aplicação. O escopado fica no meio do caminho, e é o que mais confunde porque não é definido pelo tempo em si, mas por uma fronteira. Pense no escopado como uma visita a um restaurante. O garçom da sua mesa é seu durante a refeição inteira, do momento em que você senta até pagar a conta. Todos os pedidos passam por ele. Mas assim que você sai, ele vai atender outra pessoa. Se você voltar amanhã, será um novo atendimento. Isso é o Escopado: uma instância compartilhada dentro de uma unidade de trabalho — quase sempre uma requisição web — e descartada no momento em que ela termina. Imagine uma requisição chegando a um aplicativo web. Ela precisa de uma conexão de banco de dados dentro de um repositório. No modo Escopado, esse repositório é criado uma única vez para essa requisição. Se três classes diferentes precisarem dele ao longo do processamento, todas vão receber a mesma instância. Quando a resposta é enviada de volta ao navegador, essa instância é descartada. A próxima requisição terá sua própria conexão e seu próprio repositório. Por que isso importa tanto? Porque um banco de dados se comporta de forma totalmente diferente dependendo de quanto tempo ele fica aberto. Compartilhe da forma certa durante a requisição e tudo fica consistente. Compartilhe do jeito errado e você cai na armadilha do próximo tópico.

Aproveite ainda mais o Resumo de Injeção de Dependência em .NET

Receba insights diários de mais de 100 mil lições
As palavras se destacam em sincronia com o áudio
Sua biblioteca salva em todos os dispositivos

Capítulo 9

A Armadilha da Dependência Cativa

Existe um nome para essa falha que vale a pena memorizar, porque depois que você aprende, começa a ver em todo lugar: a Dependência Cativa acontece quando algo criado para ser temporário fica preso dentro de algo construído para durar para sempre. Volte à ideia do garçom no restaurante. Imagine agora se o dono do restaurante resolvesse adotar aquele garçom como assistente pessoal permanente. Ele nunca mais trocaria de turno. Ficaria preso para sempre com alguém que nunca vai embora. No código é a mesma coisa: um serviço singleton, feito para durar a aplicação inteira, pede um repositório escopado no seu construtor. Ele recebe essa instância no momento em que é criado e a segura para sempre. O repositório que deveria se renovar a cada requisição fica preso, capturado. O problema disso não aparece em um teste manual simples. Ele aparece sob carga, semanas depois, quando duas requisições diferentes chegam ao mesmo tempo e tentam usar a mesma instância capturada e a mesma conexão de banco simultaneamente. Os dados se misturam, as threads entram em conflito e o bug é péssimo de rastrear porque cada pedaço do código parece certo isoladamente. A regra para evitar isso é bem simples: o tempo de vida de um componente nunca deve durar mais do que o tempo de vida daquilo de que ele depende. Um singleton só deve depender de outros singletons. Um objeto escopado pode depender de outros escopados ou de singletons. E um objeto transiente pode depender de qualquer coisa, porque ele não dura quase nada na memória. Guardando essa regra, a Dependência Cativa deixa de ser um mistério.

Capítulo 10

Construindo a Raiz de Composição à Mão

Tudo isso — alinhar tempos de vida, evitar dependências cativas — precisa acontecer em um lugar concreto: a Raiz de Composição. É o ponto mais próximo da entrada da aplicação onde todo o gráfico de objetos é finalmente montado. E é aqui que vale a pena mostrar como isso se parece sem um container fazendo o trabalho, no estilo chamado Injeção de Dependência Pura. Fazer de forma pura significa escrever essa montagem em código simples, direto na raiz. Parece até simples demais: um repositório é criado, envolvido em um decorador, entregue a um serviço e depois a um controlador, tudo em um bloco comum de criação de objetos. Sem mágica, sem arquivos de configuração pesados. Apenas você descrevendo o que depende do quê no único lugar do código autorizado a fazer isso. Todas as outras classes apenas recebem o que precisam pelo construtor, sem saber como aquilo foi criado. Só a raiz enxerga a estrutura inteira. E por que alguém escolheria montar tudo à mão em vez de usar um framework? Porque a Injeção de Dependência Pura deixa tudo visível para o compilador. Se você renomear uma interface, qualquer referência a ela no código avisa na hora com um erro de compilação, sem surpresas em produção. Para muitos sistemas, isso é mais do que suficiente e é o ponto de partida ideal. Claro que os sistemas crescem. Montar à mão cem serviços com caminhos diferentes pode ficar cansativo, e esse é o momento honesto de avaliar o uso de um container, como Autofac, Simple Injector ou a própria biblioteca Microsoft.Extensions.DependencyInjection do .NET. Nenhum deles muda a arquitetura por baixo. Eles só automatizam o trabalho que a Raiz de Composição já faria manualmente: construir a estrutura, respeitar os tempos de vida e entregar o objeto pronto.

Veja cada palavra enquanto a ouve

Acompanhe a leitura sem esforço enquanto cada palavra do Resumo de Injeção de Dependência em .NET se destaca em tempo real.

Capítulo 11

Decorators: Adicionando Poderes sem Mexer no Núcleo

Depois de montar a estrutura e ajustar os tempos de vida, é aqui que a arquitetura começa a dar retornos reais. Imagine que você precise adicionar logs a cada chamada de um repositório. Ou precise de um mecanismo de prevenção de falhas para parar de chamar um serviço que está fora do ar. A tentação comum é abrir a classe principal e colocar esse código direto lá. Não faça isso. Esse é exatamente o acoplamento que tentamos evitar. Em vez disso, você cria uma segunda classe que implementa a mesma interface da original e envolve a primeira. Pense em um envelope em volta de uma carta. O envelope ganha o selo, o carimbo, o endereço, mas nunca mexe no texto que está escrito dentro da carta. Um Decorator de log em volta do repositório faz a mesma coisa: ele implementa a mesma interface, então quem chama não percebe a diferença, mas antes e depois de repassar a chamada para o repositório real, ele grava o log. O repositório oficial nem sabe que o log existe. Ele só faz o trabalho dele. Um mecanismo de Circuit breaker funciona igual. Você envolve o enviador de mensagens em um Decorator que conta as falhas. Se falhar demais, ele para de tentar e avisa o sistema na hora, protegendo a aplicação. A classe original que envia as mensagens não tem nenhuma linha de código sobre contagem de erros. Ela não precisa saber que está sendo protegida. E como cada uma dessas peças implementa a mesma interface, você pode empilhá-las: um Decorator de autorização por fora de um Decorator de log, que por sua vez envolve o manipulador real. Três camadas, e cada uma só cuida do seu papel. Para adicionar ou remover uma dessas funções depois, basta mudar uma linha na Raiz de Composição, sem alterar nenhuma classe com regras de negócio. Esse é o benefício real de todo o esforço anterior: injeção por construtor, ponto único de composição e cuidado com a criação de objetos. Nada disso era preciosismo. Era o que permitia fazer alterações limpas assim.

Capítulo 12

O que Você Ganha com Isso, Muito Tempo Depois

Cada regra vista aqui se resume a uma ideia simples: coisas que mudam por motivos diferentes não devem estar soldadas no mesmo lugar. A biblioteca do banco de dados, o log, a prevenção de falhas, a regra de preço do produto — nada disso deve morar na mesma linha de código. Mantendo essas partes separadas, cada uma pode mudar, ser testada ou ser trocada sem derrubar o restante do sistema. Essa é a verdadeira recompensa, e ela raramente aparece no dia em que você escreve o código. Ela aparece meses depois, quando um desenvolvedor novo precisa trocar o banco de dados, criar uma nova funcionalidade ou rastrear um bug nos logs de produção, e descobre que consegue fazer isso mexendo em um único Decorator, em um só lugar, sem medo de quebrar o resto do sistema. A geladeira da sua cozinha não se importa com quem produziu o leite. O seu código, construído assim, também não se importa com quem criou as dependências dele. Isso não é apenas teoria. É a diferença entre ter um código em que você consegue trabalhar por anos e um sistema que todo mundo tem medo de alterar.

★★★★★

Você chegou ao fim do Resumo de Injeção de Dependência em .NET

“Já se passaram 23 dias e usei o app todos os dias. Ele agora faz parte da minha rotina.”

jayallen

Temas principais do Resumo de Injeção de Dependência em .NET

loose coupling
software maintainability
design pattern implementation
object composition
architectural seams

Melhores citações do Resumo de Injeção de Dependência em .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.

Personagens do Resumo de Injeção de Dependência em .NET

Mark SeemannAuthor and expert on software architecture

Sobre o Autor

Mark Seemann, aclamado autor de Dependency Injection in .NET e uma autoridade líder em arquitetura de software, combina décadas de experiência prática em desenvolvimento com um foco em práticas de codificação sustentáveis. Co-fundador da CloudCall Group Plc e detentor de patentes de telecomunicações, ele faz a ponte entre conceitos teóricos e aplicações empresariais do mundo real. Seu trabalho enfatiza código limpo, manutenibilidade e paradigmas de programação funcional, temas centrais em seu guia de injeção de dependência vencedor do Jolt Award e em seu livro complementar Dependency Injection: Principles, Practices, Patterns.

Além da escrita, Seemann compartilha sua expertise através de seu popular blog ploeh, cursos na Pluralsight e palestras internacionais em eventos como o NDC London. Suas percepções foram apresentadas na BBC News e CNBC, enquanto seus designs de frameworks influenciam desenvolvedores em organizações em todo o mundo.

Com mais de 15 anos de criação de conteúdo e mais de 100 palestras técnicas, ele continua moldando as práticas modernas de software. Dependency Injection in .NET permanece um texto fundamental, traduzido para vários idiomas e utilizado em programas de treinamento profissional globalmente.

Baixar resumo de Injeção de Dependência em .NET

Obtenha o resumo de Injeção de Dependência em .NET como PDF ou EPUB gratuito. Imprima ou leia offline a qualquer momento.

Usuários também gostaram

Dependency injection in .NET

Mark Seemann

Capa do livro 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

Capa do livro 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

Writing High-Performance .NET Code

Ben Watson

Capa do livro Prompt Injection: The AI Double Agent

Prompt injection explained, November 2023 edition

Prompt Injection Explained: The AI Security Problem Most People Don’t See

Prompt Injection in Vibe-Coded Apps: OWASP LLM #1 Risk Explained — 18 Free Scans for Vibe-Coded Apps

Prompt Injection: 6 Attacks and 6 Defenses | aakashx

5 sources

Prompt Injection: The AI Double Agent

Capa do livro The Pragmatic Programmer: Lessons for Modern Developers

23 sources

The Pragmatic Programmer: Lessons for Modern Developers

Capa do livro Mastering Claude Code for Full-Stack Engineering

[6f0154d2-0fff-47cb-9cda-d1157003de66:c0000] Superwall p1-1

[9a3a06d1-2061-48cb-8436-9b7bafd46461:c0000] 1694.jpg p1-1

[e6549857-3566-45de-aee8-b0e03a2927f6:c0000] 1111 p1-1

[9e57546c-0304-4f8e-94f5-8fce89085ffd:c0000] 1700.jpg p1-1

4 sources

Mastering Claude Code for Full-Stack Engineering

Capa do livro Rapid Web App Development with Claude Code

Claude Code CLI Setup 2026: 5-Minute Quickstart

Claude Code Quick Start: Zero to Productive in 2 Hours | Developer Toolkit

Cursor vs Claude Code in 2026: I Used Both for 30 Days and Here's What Changed

Claude Code vs Cursor: Which AI Coding Tool Actually Ships Faster | Sophylabs | Sophylabs

8 sources

Rapid Web App Development with Claude Code

Perguntas frequentes sobre o Resumo de Injeção de Dependência em .NET

Descubra mais

PLANO DE APRENDIZADO

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 Seções

PLANO DE APRENDIZADO

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 Seções

PLANO DE APRENDIZADO

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 Seções

PLANO DE APRENDIZADO

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 Seções

PLANO DE APRENDIZADO

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 Seções

PLANO DE APRENDIZADO

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 Seções

PLANO DE APRENDIZADO

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 Seções

PLANO DE APRENDIZADO

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 Seções

Criado por ex-alunos da Universidade de Columbia | em San Francisco

BeFreed Reúne Uma Comunidade Global De Mentes Curiosas

4.7

avaliação média

Mais de 7,84 mil avaliações do app

Comunidade BeFreed

Sério, eu ainda nem explorei o app por completo, mas só de usar nos últimos dias já fiquei impressionada… O BeFreed está em outro nível comparado a qualquer outro app de aprendizado que já usei. Ele prende demais a atenção e realmente melhora a concentração — ótimo para quem não larga o scroll!

@ladyInfinity

Comprei o BeFreed há exatamente 23 dias e uso todos os dias desde então. Ele se encaixou por completo na minha rotina de trabalho e nos meus hábitos de estudo.

@jayallen

A verdade é que o app superou todas as minhas expectativas. Posso pedir para gerar áudio sobre qualquer tema, seja qual for, e o resultado é impressionante. Minha área profissional é uma especialização em psicoterapia, bem multidisciplinar; mesmo assim, as respostas são muito precisas.

@Raguipa

O que eu mais valorizo é o quanto ele reduziu meu tempo de scroll: passo menos tempo procurando e mais tempo absorvendo informação. A combinação de audiolivros completos, podcasts e os planos de aprendizado é brilhante.

@colonyofcreatorsNGO

Sou instrutor de aprendizado acelerado PhotoReading há 24 anos… livros, leitura e aprendizado são a minha praia, e o BeFreed fez um ótimo trabalho ao trazer uma abordagem inovadora para entregar informação de um jeito fácil de consumir.

@BeFreed user

Não é só um app de resumo de livros: usei a opção de leitura divertida e é um resumo muito melhor, um jeito mais fácil de captar as ideias do que o tradicional. Só isso já vale o investimento.

@austinakon

Amo este app. Usei por vários dias e não consigo parar de ouvir. Um jeito ótimo de começar.

@jcrules328

Gosto muito do programa; já estou testando há cerca de um mês e sinto que é uma verdadeira joia. Funciona muito bem porque posso usar o BeFreed para criar meus próprios temas, e a voz é ótima, com opções ilimitadas de narração.

@DanielCZ

Sério, eu ainda nem explorei o app por completo, mas só de usar nos últimos dias já fiquei impressionada… O BeFreed está em outro nível comparado a qualquer outro app de aprendizado que já usei. Ele prende demais a atenção e realmente melhora a concentração — ótimo para quem não larga o scroll!

@ladyInfinity

Comprei o BeFreed há exatamente 23 dias e uso todos os dias desde então. Ele se encaixou por completo na minha rotina de trabalho e nos meus hábitos de estudo.

@jayallen

A verdade é que o app superou todas as minhas expectativas. Posso pedir para gerar áudio sobre qualquer tema, seja qual for, e o resultado é impressionante. Minha área profissional é uma especialização em psicoterapia, bem multidisciplinar; mesmo assim, as respostas são muito precisas.

@Raguipa

O que eu mais valorizo é o quanto ele reduziu meu tempo de scroll: passo menos tempo procurando e mais tempo absorvendo informação. A combinação de audiolivros completos, podcasts e os planos de aprendizado é brilhante.

@colonyofcreatorsNGO

Sou instrutor de aprendizado acelerado PhotoReading há 24 anos… livros, leitura e aprendizado são a minha praia, e o BeFreed fez um ótimo trabalho ao trazer uma abordagem inovadora para entregar informação de um jeito fácil de consumir.

@BeFreed user

Não é só um app de resumo de livros: usei a opção de leitura divertida e é um resumo muito melhor, um jeito mais fácil de captar as ideias do que o tradicional. Só isso já vale o investimento.

@austinakon

Amo este app. Usei por vários dias e não consigo parar de ouvir. Um jeito ótimo de começar.

@jcrules328

Gosto muito do programa; já estou testando há cerca de um mês e sinto que é uma verdadeira joia. Funciona muito bem porque posso usar o BeFreed para criar meus próprios temas, e a voz é ótima, com opções ilimitadas de narração.

@DanielCZ

Adoro poder receber informações e ideias úteis e condensadas em um áudio estilo podcast de 8 a 15 minutos. Não sou muito fã de podcasts por causa da enrolação, mas aqui vai direto ao ponto.

@BeFreed user

Estou terminando meu doutorado e preciso ler muito material desconhecido… Com o BeFreed, você só digita um prompt e o app encontra as fontes e gera um podcast em áudio. Acho o processo do BeFreed mais fluido que o do NotebookLM.

@Brad

Costumo procurar no YouTube algo para ouvir enquanto preparo o café da manhã, caminho ou me desloco, e o BeFreed oferece uma abordagem ainda mais certeira, sem anúncios e sem enrolação!

@BeFreed user

A melhor coisa desta plataforma é a versatilidade. Literalmente nenhum assunto fica de fora. Ela dá conta de tudo o que você mandar… É raro encontrar uma ferramenta de aprendizado sem limitações que realmente cumpre o que promete.

@jayallen

O BeFreed é fantástico. O design intuitivo faz com que eu passe menos tempo navegando e mais tempo aprendendo. A mistura de audiolivros, podcasts e planos de aprendizado é uma combinação genial que mudou completamente a minha rotina.

@BeFreed user

No começo, levei um tempo para entender como criar podcasts em italiano e… boom! É incrível! Posso pedir para explicar qualquer assunto e ele explica super bem, com muita inteligência!

@matteo77

O BeFreed virou meu app diário de audiolivros… O que eu mais gosto é que você coloca o seu texto e recebe um áudio para ouvir em qualquer lugar.

@kotanzu1

Adoro poder receber informações e ideias úteis e condensadas em um áudio estilo podcast de 8 a 15 minutos. Não sou muito fã de podcasts por causa da enrolação, mas aqui vai direto ao ponto.

@BeFreed user

Estou terminando meu doutorado e preciso ler muito material desconhecido… Com o BeFreed, você só digita um prompt e o app encontra as fontes e gera um podcast em áudio. Acho o processo do BeFreed mais fluido que o do NotebookLM.

@Brad

Costumo procurar no YouTube algo para ouvir enquanto preparo o café da manhã, caminho ou me desloco, e o BeFreed oferece uma abordagem ainda mais certeira, sem anúncios e sem enrolação!

@BeFreed user

A melhor coisa desta plataforma é a versatilidade. Literalmente nenhum assunto fica de fora. Ela dá conta de tudo o que você mandar… É raro encontrar uma ferramenta de aprendizado sem limitações que realmente cumpre o que promete.

@jayallen

O BeFreed é fantástico. O design intuitivo faz com que eu passe menos tempo navegando e mais tempo aprendendo. A mistura de audiolivros, podcasts e planos de aprendizado é uma combinação genial que mudou completamente a minha rotina.

@BeFreed user

No começo, levei um tempo para entender como criar podcasts em italiano e… boom! É incrível! Posso pedir para explicar qualquer assunto e ele explica super bem, com muita inteligência!

@matteo77