Escolhendo entre MEF e MAF (System.AddIn)

O Managed Extensibility Framework (MEF) e o Managed AddIn Framework (MAF, também conhecido como System.AddIn) parecem realizar tarefas muito semelhantes. De acordo com esta pergunta de estouro de pilha, o MEF substitui o System.Addin? , você pode até usar os dois ao mesmo tempo.

Quando você escolheria usar um vs. o outro? Sob quais circunstâncias você escolheria usar os dois juntos?

Estive avaliando essas opções e aqui está a conclusão que cheguei.

O MAF é uma verdadeira estrutura de complementos. Você pode separar seus complementos completamente, até executá-los em um domínio de aplicativo separado, para que, se um complemento travar, ele não interrompa o seu aplicativo. Ele também fornece uma maneira muito completa de separar os addons de qualquer coisa, exceto o contrato que você der a eles. Na verdade, você pode versionar seus adaptadores de contrato para fornecer compatibilidade com versões anteriores aos complementos antigos enquanto estiver atualizando o aplicativo principal. Embora isso pareça ótimo, ele vem com um preço muito alto que você precisa pagar para atravessar domínios de aplicativos. Você paga esse preço em velocidade e também na flexibilidade dos tipos que pode enviar e receber.

O MEF é mais como injeção de dependência com alguns benefícios adicionais, como descoberta e ... (deixando um espaço em branco neste). O grau de isolamento do MAF não está presente no MEF. São duas estruturas diferentes para duas coisas diferentes.

O que Danielg disse é bom. Eu adicionaria:

Se você assiste aos vídeos sobre System.Addins, eles estão claramente falando sobre projetos muito grandes. Ele fala sobre uma equipe gerenciando o aplicativo host, outra equipe gerenciando cada AddIn e uma terceira equipe gerenciando o contrato e o pipeline. Com base nisso, acho que o System.Addins é claramente para aplicativos maiores. Estou pensando em aplicativos como sistemas ERP como o SAP (talvez não tão grande, mas você entendeu a ideia). Se você assistiu a esses vídeos, pode dizer que a quantidade de trabalho para usar o System.Addins é muito grande. Funcionaria bem se você tivesse muitas empresas programando suplementos de terceiros para o seu sistema e não pudesse quebrar nenhum desses contratos de suplemento sob pena de morte.

Por outro lado, o MEF parece compartilhar mais semelhanças com o esquema de complemento do SharpDevelop, a arquitetura de plug-in do Eclipse ou o Mono.Addins. É muito mais fácil entender do que System.Addins e acredito que seja muito mais flexível. O que você perde é que você não obtém o isolamento do AppDomain ou os contratos de versão fortes prontos para uso com o MEF. Os pontos fortes do MEF são que você pode estruturar todo o aplicativo como uma composição de peças, para poder enviar seu produto em configurações diferentes para clientes diferentes e, se o cliente comprar um novo recurso, basta soltar a peça desse recurso no diretório de instalação e o aplicativo vê e executa. Também facilita o teste. Você pode instanciar o objeto que deseja testar e alimentá-lo com objetos simulados para todas as suas dependências,

O ponto mais importante que eu gostaria de mencionar é que, embora o System.Addins já esteja na estrutura, não vejo muitas evidências de pessoas que o usam, mas o MEF está sentado no CodePlex, supostamente, para ser incluído no O .NET 4 e as pessoas já estão começando a criar muitos aplicativos (inclusive eu). Eu acho que isso diz algo sobre os dois quadros.

Tendo desenvolvido e enviado um aplicativo MAF. Meus pontos de vista sobre o MAF estão um pouco cansados.

O MAF é um sistema "desacoplado" ou, na pior das hipóteses, um sistema "pouco acoplado". MEF é um sistema "acoplado" ou um sistema "pouco acoplado" na melhor das hipóteses.

Os benefícios do MAF que obtivemos usando o MAF são:

1. Instalando novos ou atualizando componentes existentes enquanto o aplicativo está em execução. O AddIn pode ser atualizado enquanto o aplicativo estiver em execução e as atualizações aparecerão para o usuário sem problemas. Você precisa ter AppDomains para isso.

2. Licenciamento com base nos componentes adquiridos. Poderíamos controlar quais AddIn foram carregados pela função e permissões do usuário e se o AddIn foi licenciado para uso.

3. Desenvolvimento rápido (time-to-market mais rápido). O desenvolvimento AddIn se encaixa perfeitamente com a metodologia Agile, a equipe de desenvolvimento desenvolveu um AddIn por vez, sem precisar também desenvolver a parte de integração com o restante do aplicativo.

4. Controle de qualidade aprimorado (controle de qualidade apenas um componente por vez). O controle de qualidade pode testar e emitir defeitos para um único bit de funcionalidade. Os casos de teste foram mais fáceis de desenvolver e implementar.

5. Implantação (adicione componentes à medida que são desenvolvidos e liberados e eles "simplesmente funcionam"). A implantação é apenas uma questão de criar um AddIn e instalar o arquivo. Nenhuma outra consideração foi necessária!

6. Novos componentes funcionavam com componentes antigos. Os AddIn que foram desenvolvidos desde o início continuaram funcionando. Novos AddIns se encaixam perfeitamente no aplicativo

Na minha opinião, as duas tecnologias têm como alvo casos de uso muito diferentes.

O MEF normalmente é o melhor em um cenário de injeção de dependência pura, em que a pessoa ou grupo que fornece a solução integrada final está montando tudo e atestando a integridade geral, mas precisa ter implementações diferentes dos principais recursos.

O MAF é para um cenário em que alguém / grupo está desenvolvendo uma plataforma ou host e outros grupos adicionam recursos após o fato e de uma maneira que não estão sob o controle do grupo host. Nesse cenário, é necessário mecanismos mais elaborados para "proteger" o host de suplementos não autorizados (ou para proteger suplementos um do outro).

Uma terceira tecnologia de padrão semelhante é todo o esquema do ProviderBase. Isso também permite substituir um recurso, mas seu objetivo é realmente o cenário em que o host / aplicativo precisa absolutamente de um recurso e a necessidade é realmente especificar diferentes implementações via config.

Acabei de encontrar este longo artigo discutindo o MAF e o MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

Além dos pontos apresentados pelas outras respostas, parece que uma das principais diferenças entre o MEF e o MAF é que o Managed Extensibility Framework permitiria que uma parte composível dependesse da outra. Isso permitiria que um plug-in dependesse de outro plug-in, por exemplo.

O Managed Extensibility Framework também não faz distinções entre o host e o suplemento, como o System.AddIn. No que diz respeito ao MEF, são apenas partes composíveis.

Na minha opinião, a melhor maneira de descobrir as diferenças é um código prático. Encontrei duas orientações do MSDN, ambas com um exemplo de calculadora, para que você possa comparar facilmente suas implementações:

MEF: simples exemplo calculador usando partes MEF
( M anaged E xtensibility F UADRO)

• Mostra como criar uma calculadora simples usando a tecnologia MEF. Não mostra como carregar dlls externas. (Mas você pode simplesmente modificar o exemplo usando catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); vez de usar catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));e extrair o código da calculadora e o contrato para separar projetos DLL).

• O MEF não precisa ter uma estrutura de diretórios específica, é simples e direto de usar, mesmo para pequenos projetos. Ele trabalha com atributos, para declarar o que é exportado, o que é fácil de ler e entender. Exemplo: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• O MEF não lida automaticamente com o controle de versão

MAF: calculadora simples com V1 e V2 versão plugins MAF
( M anaged A ddin F UADRO)

• Mostra como criar a calculadora usando um plug-in V1 e, em seguida, como passar para um plug-in V2, mantendo a compatibilidade com versões anteriores ( nota: você pode encontrar a versão V2 do plug-in aqui , o link no artigo original está quebrado)
• O MAF aplica uma estrutura de diretórios específica e precisa de muito código padrão para fazê-lo funcionar, portanto, não o recomendo para pequenos projetos. Exemplo:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters

MEF e MAF estão incluídos no .NET Framework 4.x. Se você comparar os dois exemplos, notará que os plugins do MAF têm muito mais complexidade em comparação com a estrutura do MEF - portanto, é necessário pensar com cuidado quando usar qual dessas estruturas.

O MAF e o MEF podem usar AppDomains e ambos podem carregar / descarregar dll em tempo de execução. No entanto, as diferenças que encontrei são: os MAF AddIns são dissociados, os componentes do MEF são soltos; O MAF "ativa" (nova instância) enquanto o MEF cria instâncias por padrão.

Com o MEF, você pode usar os Generics para criar o GenericHost para qualquer contrato. Isso significa que a carga / descarga do MEF e o gerenciamento de componentes podem estar em uma biblioteca comum e usados ​​genericamente.