Come si potrebbe fare per costruire software collegabile?


20

Se hai un'applicazione di qualche tipo e desideri che i tuoi utenti siano in grado di scrivere plugin per essa, come dovrebbe essere progettata l'applicazione?

Cosa devi prendere in considerazione, quali sono i modelli di progettazione per questo, ecc.?


Mi

3
@Mchl: inserisci la tua risposta come risposta, non come commento.
S.Lott

Dovresti dare un'occhiata a Mef e alle informazioni su MSDN
Luc Bos,

Sento che non è abbastanza dettagliato per quello
Mchl

@Mchl: "non abbastanza dettagliato"? Allora perché commentare affatto? È chiaramente una risposta. Si prega di inviare le risposte come risposte.
S.Lott

Risposte:


13

Dipende dalla tua piattaforma, ma alcune cose generali da tenere a mente

Controllo delle versioni Cosa succede se si aggiorna l'applicazione, tutti i vecchi plug-in diventano obsoleti (il problema di Firefox)

Isolamento I plugin possono fare quello che vogliono? Ti fidi sempre di loro? Oppure devi eseguirli in una sorta di sandbox e richiedere autorizzazioni.

Aggiornamenti Come gestite gli aggiornamenti dei plugin?

Sicurezza Come si garantisce l'autore di un plug-in, si evita lo spoofing o l'utente viene indotto a installare codice dannoso. Solitamente risolto da una sorta di firma del codice

Serializzazione Spesso quando si utilizza l'isolamento di qualche tipo, è necessario serializzare le informazioni tra thread o processi diversi. Come lo fai nel modo più efficiente?

Estensibilità Quali aspetti è necessario estendere? Come massimizzare il potenziale dei plugin senza che l'API diventi ingombrante.

Se ti rivolgi a sviluppatori di terze parti per i plug-in, direi che la cosa più importante (dalla mia esperienza) è vedere l'API e le classi del plug-in come completamente diversi dal resto dell'applicazione e renderlo facile da sviluppare per il più possibile. È molto facile per l'architettura dall'app principale "spostarsi" nei plug-in in modo che gli autori dei plug-in debbano imparare molto di più di quello che devono. Rendilo facile per loro, pensa a quale tipo di interfaccia ed esperienza vorresti come autore di plugin.

Un'altra buona mentalità non è quella di pensare come "Il plugin farà tutte queste cose (nel codice) ma piuttosto," il plugin deve fornire queste informazioni ". In questo modo l'applicazione può consumare le informazioni necessarie ed eseguire l'elaborazione effettiva che semplifica il plugin.

Inoltre, in generale, ogni volta che puoi seguire un approccio descrittivo (metadati, come xml) anziché un codice, hai un grande vantaggio poiché i metadati sono più facili da trasportare, versione, distribuzione, sicurezza e possono essere più facilmente configurati da terze parti


1
+1 Non risponde direttamente alla domanda, ma queste sono questioni importanti da tenere a mente
Adriano Carneiro,

Credo che questi problemi vengano affrontati prima che qualcuno inizi a sviluppare l'attuale meccanismo di estensibilità
Gus,

9

Ho scritto questo articolo di Project Code sull'uso di MEF per l'estensibilità in .NET. È una buona introduzione.

Esistono altri framework di estensibilità per .NET, come l'architettura dei componenti aggiuntivi di SharpDevelop , Mono.Addins e System.AddIn .

Per Java esiste l' architettura plug-in Eclipse .

Lo schema generale è questo:

  • Definisci un contratto (normalmente un'interfaccia) tra l'host e l'estensione
  • È necessario un meccanismo di individuazione che si spenga e cerchi le estensioni installate
  • Devi essere in grado di caricare dinamicamente le estensioni e renderne consapevole l'host

In pratica condivide molto con l'iniezione di dipendenza e il modello di strategia.


+1 MEF e System.AddIn sono entrambi cose buone da guardare. Anche se non finisci per usarli, entrambi mostrano buoni concetti.
RationalGeek,

@jkohlhepp - Sono d'accordo e suggerirei anche un tuffo nell'architettura SharpDevelop perché c'è molto scritto su di esso, è open source (così come MEF, btw) ed è ben progettato.
Scott Whitlock,

3

Hai solo bisogno di fornire un'interfaccia per i plugin.

Dovrebbe contenere almeno un Activate-Methode (un punto di ingresso), ma vorrai anche cose come Inizializza ecc.

E dovrebbe esserci la possibilità di comunicare con l'applicazione host in modo simile al registro, ad esempio per registrare voci di menu. Quindi dovrebbero essere forniti i registri per le cose che sono modificabili / estendibili per i plugin.

Inoltre, dovrebbe esserci spazio di archiviazione accessibile per i dati e gli oggetti dell'applicazione host, in modo che i plug-in possano chiamarne le routine. Questo può essere fatto facilmente utilizzando un DI-Container come Unity e consentendo ai plug-in di accedervi, in modo che possano risolvere i servizi di cui hanno bisogno.

Un Event-Aggregator è probabilmente anche una buona idea, quindi i plug-in possono generare eventi e reagire agli eventi di altri plug-in e dell'applicazione host in modo disaccoppiato. Ne vuoi sicuramente uno!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.