Para onde funciona o Managed Extensibility Framework para .NET?

Question

Alguém já trabalhou muito com o Managed Extensibility Framework (MEF) da Microsoft?Parece que está tentando ser tudo para todas as pessoas - é um gerenciador de suplementos!É digitação de pato!Gostaria de saber se alguém tem alguma experiência com isso, positiva ou negativa.

No momento, estamos planejando usar uma implementação genérica de IoC, como MvcContrib, para nosso próximo grande projeto.Deveríamos incluir o MEF na mistura?

Answer 1

Não pretendemos que o MEF seja um COI para todos os fins.A melhor maneira de pensar sobre os aspectos de IoC do MEF é detalhando a implementação.Usamos IoC como padrão porque é uma ótima maneira de abordar os problemas que procuramos resolver.

MEF está focado na extensibilidade.Quando você pensa no MEF, veja-o como um investimento para levar nossa plataforma adiante.Nossos futuros produtos e a plataforma aproveitarão o MEF como um mecanismo padrão para adicionar extensibilidade.Produtos e estruturas de terceiros também poderão aproveitar esse mesmo mecanismo.O "usuário" médio do MEF criará componentes que o MEF consumirá e não consumirá diretamente o MEF em seus aplicativos.

Imagine quando você deseja estender nossa plataforma no futuro, você coloca uma dll na pasta bin e pronto.O aplicativo habilitado para MEF acende com a nova extensão.Essa é a visão do MEF.

Answer 2

Esta postagem refere-se ao Managed Extensibility Framework Preview 2.

Então, dei uma olhada no MEF e escrevi um rápido “Hello World”, que é apresentado abaixo.Devo dizer que foi totalmente fácil de mergulhar e entender.O sistema de catálogo é excelente e torna a extensão do MEF muito simples.É trivial apontá-lo para um diretório de assemblies adicionais e deixá-lo cuidar do resto.A herança do MEF, ala Prism, certamente transparece, mas acho que seria estranho se não o fizesse, dado que ambas as estruturas tratam de composição.

Acho que o que mais me incomoda é a "mágica" de _container.Compose().Se você olhar a classe HelloMEF, verá que o campo de saudações nunca é inicializado por nenhum código, o que é engraçado.Acho que prefiro a forma como os contêineres IoC funcionam, onde você pede explicitamente ao contêiner para construir um objeto para você.Eu me pergunto se algum tipo de inicializador genérico "Nada" ou "Vazio" pode estar em ordem.ou seja

private IGreetings greetings = CompositionServices.Empty<IGreetings>();

Isso pelo menos preenche o objeto com "algo" até o momento em que o código de composição do contêiner seja executado para preenchê-lo com um "algo" real.Não sei - parece um pouco com as palavras-chave Vazio ou Nada do Visual Basic, das quais sempre não gostei.Se alguém tiver alguma opinião sobre isso, eu gostaria de ouvi-la.Talvez seja algo que eu precise superar.Ele está marcado com um grande atributo [Importar], então não é um mistério completo nem nada.

Controlar a vida útil do objeto não é óbvio, mas tudo é singleton por padrão, a menos que você adicione um atributo [CompositionOptions] à classe exportada.Isso permite que você especifique Factory ou Singleton.Seria bom ver o Pooled adicionado a esta lista em algum momento.

Não estou muito claro sobre como funcionam os recursos de digitação de pato.Parece mais uma injeção de metadados na criação do objeto, em vez de digitação de pato.E parece que você só pode adicionar mais um pato.Mas, como eu disse, ainda não estou claro como esses recursos funcionam.Espero poder voltar e preencher isso mais tarde.

Acho que seria uma boa ideia fazer uma cópia de sombra das DLLs carregadas pelo DirectoryPartCatalog.No momento, as DLLs estão bloqueadas assim que o MEF as consegue.Isso também permitiria adicionar um observador de diretório e capturar suplementos atualizados.Isso seria bastante agradável...

Por fim, estou preocupado com o quão confiáveis ​​são as DLLs adicionais e como, ou se, o MEF se comportará em um ambiente de confiança parcial.Suspeito que os aplicativos que usam MEF exigirão confiança total.Também pode ser prudente carregar os complementos em seu próprio AppDomain.Eu sei que parece um pouco com System.AddIn, mas permitiria uma separação muito clara entre suplementos de usuário e suplementos de sistema.

Ok - chega de tagarelice.Aqui está Hello World em MEF e C#.Aproveitar!

using System;
using System.ComponentModel.Composition;
using System.Reflection;

namespace HelloMEF
{
    public interface IGreetings
    {
        void Hello();
    }

    [Export(typeof(IGreetings))]
    public class Greetings : IGreetings
    {
        public void Hello()
        {
            Console.WriteLine("Hello world!");
        }
    }

    class HelloMEF : IDisposable
    {
        private readonly CompositionContainer _container;

        [Import(typeof(IGreetings))]
        private IGreetings greetings = null;

        public HelloMEF()
        {
            var catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
            _container = new CompositionContainer(catalog);
            var batch = new CompositionBatch();
            batch.AddPart(this);
            container.Compose(batch);

        }

        public void Run()
        {
            greetings.Hello();
        }

        public void Dispose()
        {
            _container.Dispose();
        }

        static void Main()
        {
            using (var helloMef = new HelloMEF())
                helloMef.Run();
        }
    }
}

Answer 3

Na questão de Andy sobre segurança para extensões que o MEF carrega (desculpe, ainda não tenho pontos suficientes :)), o local para resolver isso é em um Catálogo.Os catálogos MEF são completamente conectáveis, então você pode escrever um catálogo personalizado que valide chaves de montagem, etc., antes de carregar.Você pode até usar o CAS, se desejar.Estamos pensando em fornecer ganchos que permitam que você faça isso sem precisar escrever um catálogo.No entanto, a fonte dos catálogos atuais está disponível gratuitamente.Suspeito que o mínimo é que alguém (talvez em nossa equipe) implemente um e jogue-o em um projeto de extensão/contrib no CodePlex.

Answer 4

A digitação de pato não será lançada na V1, embora esteja no lançamento atual.Em um lançamento futuro, iremos substituí-lo por um mecanismo adaptador conectável onde se pode conectar um mecanismo de digitação de pato.A razão pela qual analisamos a digitação de pato é para abordar cenários de versionamento.Com Duck Typing você pode remover as referências compartilhadas entre exportadores e importadores, permitindo assim que múltiplas versões de um contrato vivam lado a lado.

Answer 5

Andy, acredito que Glenn Block responde a muitas perguntas (naturais) de pessoas como estas neste tópico no Fórum MEF do MSDN:

Comparação do CompositionContainer com os contêineres IoC tradicionais .

Até certo ponto, a resposta de Artem acima está correta em relação à intenção principal por trás do MEF, que é extensibilidade e não composição.Se você estiver interessado principalmente em composição, use um dos outros suspeitos usuais de IoC.Se, por outro lado, você está preocupado principalmente com a extensibilidade, então a introdução de catálogos, peças, marcação de metadados, digitação de pato e carregamento atrasado criam algumas possibilidades interessantes.Além disso, Krzysztof Cwalina dá um tiro aqui ao explicar como MEF e System.Addins se relacionam entre si.

Answer 6

Ayende também tem um ótimo artigo aqui: http://ayende.com/Blog/archive/2008/09/25/the-owned-extensibility-framework.aspx

Answer 7

Não é uma injeção de recipiente de controle.É uma estrutura de suporte de plug-ins.

Answer 8

Eu diria que, como ele ficará suspenso no namespace 'System' no .NET 4.0 Framework, você não poderia errar muito.Será interessante ver como o MEF evolui e que influência Hamilton Verissimo (Castle) tem na direção do MEF.

Se grasna como um pato, pode fazer parte do atual rebanho de contêineres de IoC...

Answer 9

Discussão mais detalhada sobre isso nesta postagem e nos comentários

http://mikehadlow.blogspot.com/2008/09/administrado-extensibilidade-framework-why.html