MEF e dipendenze circolari in MonoDevelop / VS

1

(Penso che il problema descritto di seguito influenzi anche il VS anche se l'ho provato solo in MD)

Ho qualche problema con le dipendenze circolari. So che sono cattive pratiche e dovrebbero essere evitate. Nelle versioni recenti di MonoDevelop, non puoi nemmeno creare dipendenze circolari. Tuttavia, non riesco a trovare una via d'uscita facile nel seguente scenario:

L'applicazione A utilizza il MEF (Managed Extensibility Framework) per aggiungere dinamicamente funzionalità tramite Plugin, che possono essere sviluppate da terze parti e caricate semplicemente inserendo la DLL nella cartella / cartella (DirectoryCatalog in termini MEF). / p>

Poiché sono lo sviluppatore dell'applicazione A, spedisco alcuni plug-in predefiniti insieme alla mia applicazione. I plugin possono fornire MOLTE funzionalità per estendere l'applicazione A, quindi ogni plug-in in un nuovo progetto .csproj.

Per sviluppare un plugin, uno (io stesso o qualsiasi altra parte terza) deve implementare una classe che implementa un'interfaccia. L'interfaccia, chiamiamola Interface A, è definita nell'Applicazione A ed è composta da meno di 50 righe di codice. Quindi, il plugin A richiede l'applicazione A come dipendenza, poiché l'interfaccia A è definita nell'assemblaggio dell'applicazione A. Dato che voglio utilizzare il plug-in A nella mia applicazione A, lo aggiungo anche come riferimento. E voilà, c'è un riferimento incrociato tra i due.

Ho trovato delle soluzioni, ma non sono soddisfatto di loro:

1) Creare un progetto separato e inserire SOLO il file di interfaccia al suo interno. Non mi piace perché non vedo un 50.cs essere un progetto separato e considerarlo come "eccessivamente modulare"

2) Non fare assolutamente riferimento al Plugin all'interno dell'Applicazione A (questo è possibile, poiché l'Applicazione A utilizza solo l'Interfaccia A - l'istanza della classe effettiva viene caricata dal MEF).

Questo, tuttavia, mi lascia un po 'di problemi: Non riesco a lavorare sull'applicazione A e facilmente passare al codice del plugin A per correggere sth. o aggiungere una funzionalità che faccio spesso - perché carica le funzionalità di base nei plugin (uno degli obiettivi principali di MEF è consentire la modularizzazione). Potrei comunque, avviare una seconda istanza di VS / MD. Ma questo fa male, più plug-in aggiungo, finirò per avere 10 istanze di IDE aperte - dubito che qualsiasi macchina possa gestirlo.

Quindi qualcuno ha una raccomandazione su come organizzarlo correttamente?

    
posta Dynalon 17.06.2011 - 18:05
fonte

1 risposta

0

Ho lavorato molto con MEF. Ecco come l'ho sempre strutturato:

  • ApplicationA
  • ApplicationA.Contracts
  • plugin1
  • Plugin1.Contracts
  • plugin2

(In questo esempio, Plugin1 ha punti di estensione e Plugin2 estende sia ApplicationA che Plugin1.)

Quindi, ApplicationA, Plugin1 e Plugin2 hanno tutti una dipendenza da ApplicationA.Contracts.

Plugin1 e Plugin2 hanno anche dipendenze su Plugin1.Contracts.

Gli assembly .Contracts hanno solo le interfacce, o forse anche alcuni tipi di base helper. Sì, è OK avere un piccolo assemblaggio con solo le interfacce al loro interno. Ciò assicura che Plugin1 non si interrompa quando modifichi un dettaglio di implementazione in ApplicationA e viceversa.

Se hai "roba di supporto" comune sia per ApplicationA che per Plugin1, inseriscili in un assembly di Utilities separato e fai riferimento entrambi.

L'assembly che dichiara il punto di estensione ( ImportMany nei termini di MEF) non dovrebbe mai avere un riferimento all'assieme che estende quel punto di estensione (il plugin). Pertanto, AssemblyA non dovrebbe mai fare riferimento a Plugin1 o Plugin2 e Plugin1 non dovrebbe fare riferimento a Plugin2.

Modifica

Puoi dare un'occhiata a questa applicazione MEF demo che ho scritto per vedere alcuni esempi.

    
risposta data 17.06.2011 - 18:16
fonte

Leggi altre domande sui tag