Microsoft Enterprise Library: Injeção de dependências do Unity Application Block - Parte 2

Artigo no estilo: Curso

O Microsoft Enterprise Library é formado por coleções de componentes agrupados sob a forma de application blocks. Cada uma destas estruturas engloba uma série de funcionalidades genéricas, sem uma relação direta com aspectos de um ramo de negócio e procurando atender a um tipo de demanda bem específica.

Dentre os diferentes blocos que fazem parte do Enterprise Library estão bibliotecas com recursos para a manipulação de bases de dados relacionais, tratamento de erros, validação, logging e injeção de dependências.

Além de proporcionar uma maior produtividade através da reutilização de soluções previamente testadas, os application blocks do Enterprise Library foram projetados incorporando práticas e padrões de eficácia.

Quanto às práticas favorecidas pelo Enterprise Library, merece destaque a questão envolvendo a construção de aplicações com uma menor dependência entre as diferentes partes que constituem a mesma.

Este relacionamento entre componentes de um software é conhecido como acoplamento, sendo que o ideal é que se diminua ao máximo possível esta interdependência. Um forte acoplamento é uma característica comumente encontrada em aplicações mal projetadas, sendo que mudanças em determinados pontos podem afetar de forma drástica tais sistemas.

Diversas são as soluções possíveis para isto, sendo que a técnica conhecida como injeção de dependências oferece uma alternativa bastante flexível para este tipo de demanda.

Neste segundo artigo o conceito de injeção de dependências será discutido em maiores detalhes, assim como o suporte que o Enterprise Library oferece para a implementação desta técnica. Para isto será finalizada a solução iniciada na edição passada, a partir do uso de recursos do Unity Application Block em uma aplicação construída sob a tecnologia ASP.NET MVC.

Injeção de Dependências: uma visão geral

A técnica conhecida como Injeção de Dependências procura fornecer meios para diminuir o acoplamento entre diferentes partes de um software. Em um artigo publicado em 2004 (“Inversion of Control Containers and the Dependency Injection pattern”), o renomado pesquisador Martin Fowler destacou que o padrão de Injeção de Dependências corresponde a uma variação de um conceito mais genérico chamado Inversão de Controle (termo este originário do inglês “Inversion of Control”, podendo ainda ser identificado pela forma abreviada “IoC”).

A Inversão de Controle é um pattern que enfatiza o uso da delegação, possibilitando a obtenção de classes mais coesas. A ideia principal por trás deste padrão é que um objeto transfira a execução de uma atividade específica a outro tipo, com a classe que serviu de base para a geração desta primeira instância não acumulando responsabilidades que vão além do seu objetivo inicial.

Na prática, o objeto que dispara uma ação deverá conhecer o mínimo possível de detalhes de implementação a respeito do segundo tipo para o qual é realizada tal chamada.

A Inversão de Controle é justamente o princípio seguido por frameworks e componentes projetados para reuso posterior. Importante destacar que tal separação de responsabilidades contribui para a obtenção de aplicações melhor estruturadas, menos propensas a falhas e mais flexíveis diante da necessidade quase certa de modificações futuras.

No que se refere ao padrão de Injeção de Dependências, caberá a frameworks e bibliotecas instanciar as classes das quais um ou mais tipos de objetos dependem em uma aplicação. Este processo acontece através de uma estrutura conhecida como “container” e envolve as seguintes atividades:

· Primeiramente, o container irá verificar de quais tipos depende um determinado objeto. Normalmente serão referenciadas interfaces nas classes consumidoras, como uma forma de diminuir o acoplamento para com implementações passíveis de modificações futuras. Embora menos comum, é possível ainda que sejam utilizadas classes abstratas ao i ...