Boa Idéia
Arquitetura Plugável em .Net
Construa aplicações em módulos com .NET
Nos dias de hoje, existem diversos tipos de aplicações que sofrem uma quantidade razoável de mudanças em suas regras de negócio. Além disso, a adição de novas regras também é muito freqüente. Por este fato, torna-se cada vez mais necessária a construção de aplicações que possam ser atualizadas ou estendidas com facilidade e rapidez. Um desejo comum de muitos desenvolvedores é simplesmente criar novas partes de um sistema e fazer a publicação dessas partes sem a necessidade de recompilação do “core” da aplicação. Por exemplo, imagine que você simplesmente “copiasse” um assembly contendo as novas regras de negócio para uma determinada pasta, e a aplicação host conseguisse utilizar essa nova “peça” do sistema e aplicasse essas novas regras. Ou seja, desenhar uma aplicação de forma que as peças que a componha possam ser plugadas em tempo de execução.
Não estamos falando simplesmente em “quebrar a aplicação em camadas”. Estamos falando em utilizar um componente sem a necessidade de uma “referência física” dentro do projeto que irá consumir este componente.
Ainda confuso? Vamos ver se com um exemplo as coisas ficam mais claras...
Neste artigo iremos construir uma pequena aplicação, utilizando reflection e alguns conceitos de POO (Programação orientada a objetos) para mostrar como é possível construir aplicações com uma “Arquitetura plugável” de maneira bem simples e com toda a potência, flexibilidade e desacoplamento que esta arquitetura proporciona.
O Problema
A necessidade de uma arquitetura plugável pode ser identificada em diversos cenários e não é muito difícil de ser encontrada em um ambiente real dentro de uma empresa. Aqui neste artigo, para efeito de ilustração da técnica, iremos imaginar a seguinte situação: você é o arquiteto responsável por desenhar uma solução para realizar a “integração” entre alguns sistemas de sua empresa.
A aplicação deverá, a princípio:
- Receber os dados de entrada a partir de um banco de dados ou de arquivos no formato “texto”. Porém, diversos outros tipos de fontes de dados poderão “aparecer” com o decorrer do tempo, como por exemplo, receber os dados através de um web services ou através de FTP (File Transfer Protocol).
- Processar os dados de entrada, aplicar alguma lógica de negócio, que pode variar bastante, e gerar uma saída que seja entendida pelo segundo sistema.
- Enviar esses dados para o segundo sistema, gerando um novo arquivo ou mesmo enviando o resultado via e-mail para os envolvidos no processo. Mais uma vez, diversos outros tipos de saída poderão também surgir, como por exemplo, salvar os dados em outra base de dados ou enviá-los via FTP.
Como nós podemos ver, existe uma série de possibilidades relacionadas tanto à entrada de dados quanto à saída, dependendo dos sistemas que nós desejamos integrar. Além disso, seria interessante pensar em uma maneira de atualizar ou acrescentar uma nova “integração” de sistemas, sem a necessidade de deixar as demais “fora do ar”.
Desenhando a solução
A solução de exemplo será composta de uma parte “fixa” (host) e de pequenas peças plugáveis (plug-ins). Essas “peças” deveriam ser encaixadas dentro do host sem a necessidade de recompilação do mesmo e sem a necessidade de “referenciar” esse novo componente em “tempo de design”. O ato de “encaixar” um plug-in significa somente copiar uma DLL (dynamic link library) para uma pasta específica e o host deverá ser capaz de reconhecer aquele novo plug-in e passar a utilizá-lo. Pode parecer meio complicado, mas tanto a idéia quanto a implementação são bastante simples.
Com a finalidade de simplificar, o ...
