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.

Demais posts desta série:
MEF - Parte 1
Artigo no estilo: Curso

Do que trata o artigo

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.

Para que serve

O MEF é um meio padronizado, conceitualmente menos sujeito a erros, que deve ser utilizado por quem precisa desenvolver softwares que sejam extensíveis dinamicamente através de plugins e não precisa se preocupar com os detalhes da infraestrutura necessários para isto.

Em que situação o tema é útil

Se o seu aplicativo precisa suportar extensão dinamicamente o MEF será de grande utilidade.

Resumo do DevMan

O MEF (Managed Extensibility Framework) é uma biblioteca do .NET framework 4 para criação de programas que podem ser estendidos dinamicamente (plugins no jargão de desenvolvimento de programas). Nesta segunda parte do artigo serão abordados os conceitos por trás do MEF e migração do pequeno aplicativo criado na parte 1.

Sendo esta a segunda parte, faremos algumas referências ao artigo anterior, que pode ser encontrado na edição 73 da .net Magazine. Este artigo tratou de alguns princípios de design utilizados em programas extensíveis (dinamicamente ou não) e mostrou uma forma “old school” de criar um mecanismo de plugins e consumi-lo em um aplicativo. Nesta segunda parte vamos partir da comparação com a primeira e explorar alguns pontos da biblioteca de gerenciamento de extensibilidade (MEF) do .NET framework.

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."

[...] continue lendo...

Artigos relacionados