Sistema com plugins em c #

Eu tenho que desenvolver um sistema para monitorar as informações do sensor, mas muitos sensores podem ser adicionados no futuro.

Dito isto, a ideia seria desenvolver um sistema que consistiria no esqueleto da aplicação. Os sensores (como cada um deles tem suas características de comunicação e apresentação de dados) seriam adicionados como plugins ao sistema.

Como eu iria codificar isso em c #? É um caso de desenvolvimento orientado a componentes? Devo usar bibliotecas dinâmicas?

Há um grande número de sistemas plug-in ad-hoc para o C #. Um é descrito em Arquitetura de Plugin usando C # (no The Code Project ). A abordagem geral é que o aplicativo host publica um assembly com interfaces. Ele enumera por meio de uma pasta e localiza conjuntos que definem uma class que implementa suas interfaces e as carrega e instancia as classs.

Na prática, você quer fazer mais. É melhor se o aplicativo host definir duas interfaces, um IHost e um IPlugIn. A interface do IHost fornece serviços aos quais um plug-in pode se inscrever. O IPlugIn é construído com um IHost.

Para carregar um plug-in, você deve fazer mais do que simplesmente obter um plug-in. Você deve enumerar todos os plug-ins que podem ser carregados. Construa cada um deles. Pergunte se eles podem correr. Peça-lhes para exportar APIs para o host. Peça-lhes para importar APIs do host. Os plug-ins devem poder perguntar sobre a existência de outros plug-ins.

Dessa forma, os plug-ins podem estender o aplicativo oferecendo mais APIs.

PlugIns deve include events. Desta forma, os plug-ins podem monitorar o processo de carregamento e descarregamento de plug-ins.

No fim do mundo, você deve avisar os plug-ins que eles vão desaparecer. Então tire-os.

Isso deixará você com um aplicativo que pode ser escrito em um framework minúsculo e implementado inteiramente em plug-ins, se você quiser.

Como um bônus adicional, você também deve fazê-lo para que, na pasta de plug-ins, você resolva os atalhos para os plug-ins. Isso permite que você escreva seu aplicativo e entregue-o a outra pessoa. Eles podem criar um plug-in em seu ambiente de desenvolvimento, criar um atalho para ele na pasta de plug-ins do aplicativo e não precisar se preocupar com a implantação após cada compilation.

O Extensibility Framework Managed (MEF) é o que você precisa aqui. Você também pode usar um contêiner de injeção de dependência , mas isso não é o que você esperaria, embora seja uma solução perfeitamente viável por si só.

Cada sensor deve implementar uma interface padrão para que as rotinas que lidam com listas de sensores possam tratá-las de maneira padrão. Inclua um campo de ID na interface que seja exclusivo também para cada tipo de sensor, para que você possa lidar com casos especiais.

Olhe para a Reflection API para aprender a varrer um diretório de .NET Assemblies e olhar dentro deles.

Cada assembly deve ter uma class de fábrica que o trabalho é retornar uma lista de sensores que estão nessa assembly. Eu recomendo que você faça uma sub-rotina e não uma function e passe uma lista que ela também acrescente. O SensorDLL1 acrescenta 4 sensores à lista vazia, o SensorDLL2 acrescenta 8 sensores à lista que agora possui 12 sensores e assim por diante. Essa abordagem é a mais flexível a longo prazo.

Você terá que criar uma convenção de nomenclatura para localizar a class de fábrica ou usar um atributo. Nota Não recomendo apenas escanear a assembly para tudo o que implementa a interface do seu sensor, pois você pode ter código dentro da fábrica que controla quais sensores estão disponíveis. Isso é útil para licenciamento.

Dependendo dos próprios Sensores, isso soa como se você precisasse definir uma única interface que todos os sensores implementariam. Seu “esqueleto de aplicativo” principal funcionará então na interface do ISensor e não precisará se preocupar com as implementações concretas de cada uma das classs / objects / componentes do Sensor.

Se cada Sensor é simplesmente uma class dentro do mesmo projeto, ou uma assembly separada, depende de você, embora, se forem montagens separadas, você precisaria de uma maneira de carregar esses conjuntos dinamicamente.

Algumas referências que podem ajudar aqui são:

Padrão de Design de Padrão de Comando: – http://en.wikipedia.org/wiki/Command_pattern

Padrão de Design de Padrão de Observador: – http://en.wikipedia.org/wiki/Observer_pattern

Carregando dinamicamente conjuntos: – http://www.divil.co.uk/net/articles/plugins/plugins.asp

Espero que isto ajude.

Certa vez, fizemos um sistema plug-in em um projeto escolar nosso em 2006, o Socio. Você pode encontrar o código aqui e aqui .

A lição básica aprendida foi que é muito simples carregar dinamicamente o código em C #. Se você tiver apenas uma DLL de plug-in e um aplicativo que adere a uma interface sua e links contra uma DLL comum na qual essa interface existe, ela simplesmente funciona.

Em essência, é o que o plinto descreveu em sua resposta .

Dê uma olhada:

Bloco de aplicativos de interface do usuário composto e fábrica de software do cliente inteligente

É um post muito antigo, mas ainda achei que seria útil para alguém para appPress.in onde desenvolvemos um framework com funcionalidade de plugins. aqui permitimos que o plugin modifique a interface do usuário do aplicativo principal Horizontalmente e Verticalmente, adicione suas próprias Páginas, conecte-se a events como Init, OnClick e OnChange.