Este é um post disponível para assinantes MVPMEF – Parte 2 - .Net Magazine 74
Este artigo é a segunda parte de uma discussão sobre programas extensíveis. Na primeira parte falamos um pouco sobre princípios de design e fizemos um gerenciador de plugins bem simples. Nesta segunda parte vamos focar sobre o MEF e ver o quanto de trabalho esta biblioteca pode nos poupar.
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 74
MEF – Parte 2
Como o próprio nome diz, MEF trata-se de uma biblioteca para facilitar a criação de programas que suportem plugins. Com esta biblioteca haverá um meio padronizado de resolver esta categoria de problema.
Alguns problemas são bem mais comuns do que outros. Acessar um arquivo é bem mais comum para a maioria de nós do que fazer um aplicativo com suporte a plugins. Para fazer um aplicativo com suporte a plugins, no entanto, uma parte significativa do código é destinada à infraestrutura. Isto por si só já justifica a criação de uma biblioteca. Se ela for mantida dentro do .NET framework, em minha opinião, melhor ainda. Levando-se em consideração o exemplo criado na primeira parte deste artigo, o que teríamos de reescrever caso quiséssemos estender outro aplicativo?
· Interfaces de plugins (varia conforme a necessidade);
· Plugins que implementam as interfaces (varia conforme a necessidade);
· Estrutura para carga dinâmica dos plugins (infraestrutura que não deveria variar).
A implementação daquele artigo criou uma classe para carga de plugins casada com uma interface (contrato) específica. Não obstante, seria relativamente simples implementá-la de forma genérica para fazê-la funcionar com mais de um tipo de plugin e poder ser reutilizada em outras situações. Aqueles plugins, por outro lado, eram totalmente independentes. Imagine que evoluíssemos aquele componente para suportar e entender as dependências entre os plugins. A implementação do container já ficaria bem mais complexa.
De fato, fazer um mecanismo decente para descoberta e gerenciamento de plugins levaria um bom tempo e não teria quase nada a ver com o negócio propriamente dito. Forçando um pouco (ou muito), seria algo como ter que escrever o ADO.NET para poder criar um programa de faturamento. Exageros à parte, o MEF se encaixa exatamente aí. Ele permite que os programadores coloquem o foco no negócio (o aplicativo e seus plugins) ao invés de terem que pensar na infraestrutura.
A arquitetura do MEF
No exemplo do artigo anterior eu utilizei uma nomenclatura específica para poder traçar um paralelo nesta segunda parte. Naquele exemplo havia um catálogo que era um diretório no qual os plugins estavam armazenados, um container (BusinessIndicatorPartContainer) que era a classe responsável pela descoberta e criação dos plugins em tempo de execução e as partes (IBusinessIndicatorPart) que eram os plugins propriamente ditos. Os principais componentes do MEF são conceitualmente muito parecidos com aqueles propostos na parte 1 deste artigo, conforme você pode ver na Figura 1.

Figura 1. Visão simplificada das partes principais do MEF
Esta figura apresenta três dos principais componentes do MEF, sendo que as parts (ou ComposableParts) têm um papel fundamental para o negócio. É nas parts que residirá o nosso código. Uma part pode dizer o que ela exporta para o mundo exterior e o que ela importa. Este esquema de importação e exportação se dá através de contratos que funcionam como uma espécie de ponte entre os dois lados, sendo que os contratos são normalmente definidos por interfaces. Os catalogs, como o próprio nome diz, são responsáveis por catalogar as partes que estarão disponíveis para que os containers possam utilizá-las de forma a analisar suas dependências e fornecer uma visão/ligação organizada em tempo de execução.
Migrando o exemplo da parte 1 para MEF
Como já foi dito aqui, o exemplo proposto na parte 1 era conceitualmente bem próximo do que vamos fazer no MEF. Para fazer esta migração vamos utilizar basicamente os mesmos componentes com algumas modificações e vamos excluir o mecanismo de plugins, já que ele será substituído pelo MEF nesta tarefa. Para iniciar, vamos voltar à definição da interface dos nossos plugins (Listagem 1).
· Listagem 1. Interface IContract
public interface IContract : IDisposable
{
string Name { get; }
string Description { get; }
string Company { get; }
}
//Interface para os plugins de indicadores de negócio.
public interface IBusinessIndicatorContract : IContract
{
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Space do autor



0
0
