Padrões de DI: Register Resolve Release

Olá, pessoal

De volta com a série “Padrões de DI”,  entendam este terceiro e breve post como um complemento ao post anterior, com o objetivo de explicitar mais um conceito referente ao tema “Injeção de Dependência”: o padrão Register-Resolve-Release.

Enquanto o Composition Root nos diz ONDE usar um DI container, o padrão Register-Resolve-Release nos diz COMO usá-lo.

Este padrão afirma que devemos chamar os métodos do container na sequência – Register, Resolve e Release – e em nenhuma outra sequência.

O método Register registra os componentes no container, de forma que este saiba resolver as dependências durante a execução da aplicação.

O método Resolve resolve (quem diria, hein!?) um gráfico de dependências. Em uma aplicação web, ele é executado a cada requisição http para resolver o controller e suas dependências.

O método Release é chamado para liberarmos os objetos da memória, para cada Resolve chamado. Novamente, em uma aplicação web, ele é executado ao fim da requisição http, para liberar o controller e suas dependências.

Em se tratando do número de ocorrências desses métodos na base de código, os métodos Resolve e Release devem aparecer uma única vez (no exemplo da aplicação ASP.NET MVC, eles só aparecem na implementação da controller factory). Já a chamada ao método Register pode aparecer uma ou mais vezes para registrar os componentes (ainda assim somente no start da aplicação).

Vale lembrar que os nomes dos métodos variam de container para container, mas o propósito deles é exatamente o mesmo. No Ninject, por exemplo, o método Register é chamado de Bind.

Já vimos o uso desse padrão no <post anterior>, quando implementamos o Composition Root de uma aplicação ASP.NET MVC. Percebam, no código daquele post, que a sequência em que os métodos aparecem segue o padrão Register-Resolve-Release.

Sabendo onde (Composition Root) e como (Register-Resolve-Release) usar o container de DI, podemos partir nos próximos posts para os padrões de DI relacionados diretamente ao design da aplicação, começando pelo mais comum deles: Constructor Injection.

Até lá!

Anúncios

Participe! Vamos trocar uma ideia sobre desenvolvimento de software!

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s