Artigos .NET DI com Unity Application Block
Artigo do tipo Exemplos Práticos
Recursos especiais neste artigo:
Conteúdo sobre boas práticas.
DI com Unity Application Block
Uma das melhores maneiras de aumentar o desacoplamento de nossos softwares é utilizando a prática de injeção de dependências (DI), sendo que esta prática pode ser utilizada de maneira manual ou através de um framework. Neste artigo, iremos apresentar como realizar injeção de dependência em nossas aplicações utilizando o framework Unity Application Block (UAB), com o intuito de prover um desenvolvimento totalmente orientado a componentes desacoplados e reutilizáveis. Para demonstração deste processo, faremos um exemplo prático com uma aplicação de acesso a dados utilizando ASP.Net MVC e Entity Framework Code First.

Em que situação o tema é útil
O uso de injeção de dependências em softwares orientados a objetos possibilita um grande desacoplamento na aplicação. Com isso, esta técnica pode ser usada em qualquer camada de sua aplicação, trazendo como benefícios um maior nível de reusabilidade e testabilidade em seu código.

A programação de componentes reutilizáveis é considerada uma boa prática de programação, de onde surge o antigo jargão de desenvolvimento “reinventar a roda”. Para que refazer algo que está bem codificado e plenamente funcional? É simplesmente desnecessário.

Em sintonia com a reciclagem de classes, existem inúmeros padrões de projetos para praticamente todas as plataformas existentes e um que está em grande evidência é o padrão de Injeção de Dependências (Dependency Injection), também comumente conhecido como DI (sigla em inglês).

O padrão de injeção de dependências e inversão de controle é fascinante, tendo em vista que nele tratamos classes como objetos em um mundo virtual plenamente organizado, dividindo cada responsabilidade para seus executores em seus devidos escopos. É a mais pura aplicação da “Orientação a Objetos”.

Este padrão de projetos é largamente utilizado por desenvolvedores em todo o mundo por conta da sua simplicidade, assim como pela divisão de tarefas entre objetos da aplicação de forma encadeada.

Analogamente, imagine uma oficina mecânica como uma aplicação. A própria oficina tem escopo global, dentro da qual todos os demais objetos interagem. As ferramentas e os funcionários têm como domínio o seu departamento e suas atividades, cada um com um papel pré-definido, como ilustrado na Figura 1.

Figura 1. Diagrama de uma oficina

O carro chega à oficina e logo é acionado um mecânico para um serviço específico. Um mecânico depende da pré-existência das ferramentas e da oficina, enquanto que o carro, para ser avaliado, precisa de um mecânico. Na Listagem 1 observa-se um exemplo de implementação das classes de domínio do cenário em questão:

Listagem 1. Modelo de domínio da oficina


1  public class Oficina
2  {
3 
4  }
5 
6  public class Ferramenta
7  {
8    public Oficina Oficina { get; set; }
9  }
10
11 public class Mecanico
12 {
13   public Ferramenta Ferramenta { get; set; }
14 }
15
16 public class Carro
17 {
18   public Mecanico Mecanico { get; set; }
                                    
19 }

Veja que no nosso modelo de domínio os objetos são interdependentes, mas ainda não definimos qual o mecanismo responsável por coordenar a atuação e a instanciação destes objetos. Portanto, neste momento entra o trabalho do Unity Application Block, que é uma ferramenta leve, fácil e intuitiva, utilizada para engenharia de software baseada em componentes desacoplados.

A arquitetura por trás do Unity

No modelo de Injeção de Dependências, o responsável por gerenciar instâncias e escopos de objetos é o contêiner, que resolve instâncias dos objetos por intermédio de um dependency resolver. Os objetos necessariamente possuem uma vida útil, seja durante toda a aplicação, apenas durante uma requisição web, ou durante o tempo de vida de um formulário. O responsável pelo tempo de vida de cada objeto é o lifetime manager (gerenciador de tempo de vida).

...

Quer ler esse conteúdo completo? Tenha acesso completo