Usando uma classe abstrata como contrato na estrutura do plug -in
-
22-09-2019 - |
Pergunta
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?
Solução
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 ).
Outras dicas
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 ...
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.
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).