DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!


MEF – 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.






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
Este post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!






    0 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.


Nenhum comentário foi postado - seja o primeiro a comentar!



Publicidade
Autor
Marcelo Palladino

Marcelo Palladino (marcelopalladino@uol.com.br), trabalha profissionalmente com desenvolvimento à 16 anos. Neste período participou de projetos em empresas como Banco do Brasil, Embratel, Banco Safra, Rede Globo entre outras. Atualmente atua como desenvolvedor no grupo Sonda IT.


Space do autor
Estatísticas
Favorito:
Comentários:
Feedback:
Utilidade:
0   0
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2012 - Todos os Direitos Reservados a web-03