Usando uma classe abstrata como contrato na estrutura do plug -in

Question

Uma classe abstrata pode ser usada como objeto de contrato entre um 'host' e um 'plugin'? A idéia é que o plug -in herde o contrato (chamamos de adaptador). Também estamos entendendo que todos os participantes da estrutura devem herdar MarshalByRefObject (Mbro). Então, é isso que estávamos pensando -

Hospedeiro:

class Host : MarshalByRefObject
{
}

Contrato:

public abstract class PluginAdapter : MarshalByRefObject
{
}

Plugar:

class myPlugin : PluginAdapter
{
}

Todos os três existem em ASMs separados. Nosso host criará um novo AppDomain para cada plug -in, e o pluginadapter será criado da seguinte forma:

{
    ObjectHandle instHandle = Activator.CreateInstance(
    newDomain, data.Assembly.FullName, data.EntryPoint.FullName);

    PluginAdapter adapter = (PluginAdapter)instHandle.Unwrap();
}

EDITAR: Onde data é o tipo concreto de myPlugin.

Estávamos nos perguntando se essa implementação da estrutura funcionaria. Vimos artigos usando uma interface (iplugin) para a derivação do plug -in e uma classe de concreto como contrato. Esses artigos também diriam que uma classe abstrata pode ser usada, mas não há exemplos dessa implementação. É necessário que o contrato seja uma classe concreta?

EDITAR: Neste exemplo, de Richard Blewett - C# Reflexão - Ele usa uma implementação muito mais simples:

Contrato:

public interface IPlugIn  
{  
    // do stuff  
}

Plugar:

public class PlugIn : MarshalByRefObject, IPlugIn  
{  
}

Agora, se estiver usando uma classe abstrata como contrato, o plug -in não pode herdar o contrato e o MBRO. O que, então, se torna a melhor implementação para uma estrutura de plug -in escalável. Devemos prosseguir e implementar o mesmo, mesmo assim, inicialmente, estamos desenvolvendo para operação de máquina única? Espera -se que este projeto seja distribuído em uma rede, possivelmente na Internet também. Simplesmente ainda não implementamos o TCP porque estamos tentando obter o básico de uma estrutura de plug -in totalmente compreendida e operacional.

Faz sentido implementar o TCP Remoting em uma única máquina usando loopback?

Answer 1

Parece que o jetbrains está planejando adicionar o suporte do MSBuild 4.5 à próxima versão menor de TeamCity (consulte o problema TW-20629 ).

Answer 2

Fornecido "data.entrypoint.fullName" é o nome completo do tipo, o código acima deve funcionar.

No entanto, se você está tentando manter esse tipo isolado em seu próprio aplicativo, deve ter cuidado aqui. Fazendo data.Assembly, você puxará a montagem (e seus tipos) para o seu aplicativo, fazendo com que os tipos sejam carregados no aplicativo AppDomain ...

Answer 3

Você pode querer dar uma olhada em MAF (a estrutura de addin gerenciada) que é uma estrutura de extensibilidade embutida no .NET para fazer addins. É semelhante (e mais velho) do que MEF (estrutura de extensibilidade gerenciada), mas tem mais opções no que diz respeito a manter os plugins em seu próprio domínio de aplicativos, entre outras coisas.

Answer 4

Se data.EntryPoint.FullName refere -se ao tipo de concreto myPlugin Não vejo nenhum motivo para que isso não funcione (a menos que tenha problemas de carregamento de montagem no outro aplicativo, mas esse é um problema diferente).