{.NET » C#} Plugin-Architektur individuell entwickeln oder bestehendes Framework verwenden? @CODEKICKER

Plugin-Architektur individuell entwickeln oder bestehendes Framework verwenden?

                    Hallo zusammen, ich überlege gerade wie ich eine Windows Forms Anwendung am besten mit Plugins erweiterbar mache. Gibt es hier bestehende Frameworks mit denen ihr bereits Praxiserfahrungen sammeln konntet? Ich könnte einfach Assemblies zur Laufzeit nachladen, die eine gemeinsame Schnittstelle verwenden, bin mir allerdings nicht sicher, ob ich damit das Rad neu erfinde oder ob es vielleicht einen "Königsweg" gibt.
                    
                

News:

24.02.2011

Torsten Weber

691 ● 1 ● 8

Editiert 09.03.2011

Torsten Weber

691 ● 1 ● 8

		Handelt es sich um grafische-Plugins oder normale Klassen? – Konstantin 24.02.2011
		Mir geht es um generelle Erweiterbarkeit einer Architektur. Das können z.B. Assistenten sein, nur Dialoge oder kleine Erweiterungen die Berechnungen/Algorithmen kapseln. – Torsten Weber 24.02.2011
		Vielen Dank für eure zahlreichen Antworten, ihr habt mir sehr geholfen und ich habe mich nun für MEF entschieden. Das scheint tatsächlich eine Variante zu sein, die genau für meine Anforderungen passt. – Torsten Weber 25.02.2011

10 Antworten

                    Zu deinem Kommentar meiner ersten Antwort:

1. MEF ist Bestandteil des Frameworks 4.0
2. IMHO sehr kurze Einarbeitungszeit

Ich verwende noch beide von mir genannten Varianten:
Serverseitig sind DataAccessLayer und BusinessLayer durch MEF entkoppelt. D.h. die Assemblies haben keine Referenzen mehr aufeinander sondern kommunizieren durch MEF (Interfaces). Somit ist der DataAccessLayer ohne großen Aufwand austauschbar. Er muss lediglich die Interfaces implementieren.
Das Verhalten ist bei Addins das Gleiche. Assembly in ein Verzeichnis kopieren, das ein definiertes Interface implementiert und schon kann es durch MEF verwendet werden. Die eigentliche Anwendung muss nicht neu kompiliert werden, da sich keine Verweise ändern.
Hier muss ich sagen, hat mich die Einfachheit der Implementierung von MEF überzeugt.

Clientseitig (Silverlight) arbeite ich immer noch ohne MEF (das kann sich ändern) und verwende zum Laden der Assemblies "System.Net.WebClient" und "System.Windows.AssemblyPart" und instanziiere per "System.Activator", also Reflection.
Für meinen Teil fand ich die eigene Lösung nicht komplizierter und erfüllt seinen Zweck.

ABER:
 - MEF wird weiterentwickelt, meine eigene Lösung eher nicht.
 - Weitere Entwickler kennen vielleicht MEF, aber meine selbstgehäkelte Lösung nicht.

Abschließender Tipp:
Die Einarbeitungszeit in MEF ist so gering, dass du es ausprobieren kannst, ohne viel Zeit zu verlieren. Danach kennst du MEF, kannst entscheiden, ob es passt und hast schlimmstenfalls nichts außer etwas Zeit verloren.
                    
                

24.02.2011

Jürgen Luhr

7,1k ● 2 ● 9

Noch ein Vorteil von MEF: dadurch das es Bestandteil vom Framework und z.Z. auch in vieler Munde ist, mangelt es im Internet nicht an Beispielen.

– Jorgen Schumann 24.02.2011

Hierfür eignet sich MEF ganz gut. Beispiele gibt es genügend c-adding-controls-in-winform-via-plugin-dll

Ergänzung:
Natürlich kann man auch Meta-Informationen in einer Textdatei (z.B. XML) hinterlegen, eine Assembly laden und per Reflection instanziieren. Das wäre eine recht einfache Variante.
Ich würde aber gleich MEF nehmen.

24.02.2011

Jürgen Luhr

7,1k ● 2 ● 9

Editiert 24.02.2011

Jürgen Luhr

7,1k ● 2 ● 9

		MEF wäre eine Variante auf die ich auch gestossen bin. Ich habe diese Links ja auch gefunden. Mir geht es in erster Linie um Praxiserfahrungen. Aus welchem Grund sollte ich Deiner Meinung nach MEF verwenden? – Torsten Weber 24.02.2011
		Da ich die verfügbare Anzahl an Zeichen für einen Kommentar deutlich überschreite, findest du meinen Kommentar als Antwort. s. u. – Jürgen Luhr 24.02.2011
		Du hättest auch einfach Deine bestehende Antwort editieren können. ;-) – Torsten Weber 24.02.2011

Beim Nachladen von Assemblies muss man bedenken, dass einmal geladene Typen während der Laufzeit erhalten bleiben. Weiterhin können Fehler die in den Plugins auftreten die eigene Applikation schädigen.

Dies kann man nur umgehen indem man die Assemblies in eine andere Appdomain lädt. Dann wird aber wiederum die Kommunikation zwischen den Assemblies recht aufwändig. Du kannst dafür andererseits auch MAF verwenden.

Vielleicht brauchst du aber auch gar keine wirklichen Plugins. Dann solltest du auf MEF oder ein anderes IoC-Framework zuück greifen. Das macht zudem die Unit-Tests wesentlich einfacher.

Nach deiner Fragestellung würde ich dir zu letzterem raten. Unity und MEF habe ich als recht einfach in Erinnerung und sollte deine grundsätzliche Anforderung mehr als erfüllen.

24.02.2011

Hendrik Lösch

1,5k ● 1 ● 9

Editiert 24.02.2011

Hendrik Lösch

1,5k ● 1 ● 9

1		Ich persönlich setze MAF in einer größen Anwendung ein und ich muss sagen, ich bin sehr zufrieden. Klar man muss sich einarbeiten und die Strukturen verstehen, aber wenn man das verstanden hat, ist es ein sehr mächtiges und solides Framework. – Konstantin 24.02.2011
		Ah, jetzt kommen wir der Sache schon näher: "MAF in einer großen Anwendung ... bin sehr zufrieden". Sowas meinte ich mit meiner Frage. Hast Du Dich vorher gezielt gegen andere Frameworks entschieden oder passte MAF sofort? – Torsten Weber 24.02.2011

Weitere Beispiele mir Source-Code:
http://www.codeproject.com/KB/library/PluginFramework.aspx
http://www.codeproject.com/KB/gadgets/pluginmanager.aspx
http://www.codeproject.com/KB/cs/dynamicpluginmanager.aspx

24.02.2011

220 ● 3

                    Ich schliesse mich Jürgen an, denn MS hat MEF zum Bestandteil des Frameworks gemacht und nicht Unity, die EntLib oder CAL. Das deutet ja darauf hin wo die Reise(Attribute, Container) hingeht. Ich habe 2010 mit einer Neuentwicklung begonnen und von vornherein auf MEF gesetzt. In der neuen DNP wird auch AIFramework vorgestellt. Sicher eine tolle Sache, aber wenn ich eine Große, über viele Jahre funktionierende Software schreibe und weiterentwickele, dann würde ich erst dann auf andere Hersteller zurückgreifen wenn das Framework es nicht hergibt oder keine Zeit zum selberschreiben da ist. Was ist wenn der Hersteller pleite geht oder in der Komponente ein Bug ist, der erst nach Jahren auftaucht.
                    
                

24.02.2011

Jorgen Schumann

1,6k ● 2 ● 9

Oder aus Patters & Practice den CAB:
http://compositewpf.codeplex.com/
http://www.codeproject.com/KB/WPF/GoalBook.aspx
Arbeitet mit Unity, ist evlt. nicht mehr ganz "zeitgemäß"!?

http://briannoyes.net/2008/10/13/CompositeExtensionsForWindowsForms.aspx

24.02.2011

Jorgen Schumann

1,6k ● 2 ● 9

Editiert 24.02.2011

Jorgen Schumann

1,6k ● 2 ● 9

		Du verlinkst auf zwei Quellen, die sich mit WPF- bzw. Silverlight-Entwicklung befassen. Torsten hat nach Windows Forms gefragt. Composite WPF, aka Prism, ist von der Aufgabenstellung her ein Nachfolger von CAB, hat aber sonst nicht viel damit zu tun. Den CAB gibt es m.W. schon längere Zeit nicht mehr stand-alone, sondern nur als Teil der Smart Client Software Factory. Keine Ahnung, ob die noch gepflegt wird, aber empfehlen kann ich sie aus eigener Erfahrung nicht. Und warum findest Du Unity nich mehr zeitgemäß? Ist ein DI-Container wie andere (Spring, Lightcore, Pico...) auch. – Matthias Hlawatsch 24.02.2011
		Du hast Recht, es gibt sicher besser Quellen welche die Verwendung mit WindowsFroms demonstrieren. – Jorgen Schumann 24.02.2011
		... und mir geht es um konkretes Für und Wider. Tutorials finde ich mit Google wie Sand am Meer. Mir geht es um Empfehlungen oder Warnungen. – Torsten Weber 24.02.2011

                    Ich finde, Jorgen vergleicht in seinem zweiten Post, in dem er sich Jürgen anschließt, Äpfel mit Birnen. Unity ist ein DI-Container, die Enterprise Library eine Sammlung von verschiedenen Komponenten, die z.T. auf Unity aufbauen, und CAL (Prism) ein Framework zur Modularisierung von WPF-/Silverlight-UIs, das ebenfalls auf Unity aufbaut. Keines davon ist als allgemeines Plugin-Framework gedacht, im Gegensatz zu MEF. Insofern ist die Empfehlung für MEF an sich zwar richtig, aber das Argument zielt in die falsche Richtung: Dass MEF Bestandteil des Frameworks geworden ist, heißt nicht, dass die anderen ihre Daseinsberechtigung verloren haben. Prism kann man wohl sogar mit MEF integrieren, soweit ich weiß.
AiFrame enthält, soweit ich den dotnetpro-Artikel verstanden habe, auch ein Plugin-Framework, hat aber einen spezialisierten Scope auf Geschäftsanwendungen und bietet dafür für diese auch noch weit mehr als nur Plugin-Funktionalität.

24.02.2011

Matthias Hlawatsch

13,2k ● 4 ● 9

                    Ich würde MEF zwar schon mit einigen DI Containern vergleichen, im Herz ist es aber ein Pluginsystem.
Ich musste MEF mühselig beibringen als DI zu funktionieren und das ist verdammt hässlich.

Also , wenn du in deinem Projekt auf .NET 3.5 - 4.0 aufbauen kannst nutze MEF, es gibt nichts einfacheres. Unter 3.5 kannst du immerhin noch Reflection etc.nutzen.

Grüße

24.02.2011

Pawel Warmuth

195 ● 1 ● 6

Möglichkeit eine WindowsForms Anwendung mit System.Addin zu erweitern : http://www.dotnetpro.de/articles/showarticle.aspx?id=2784

24.02.2011

Jorgen Schumann

1,6k ● 2 ● 9

                    MEF und nur MEF.
Es ist einfach und funktioniert bestens.
Alte Regel von mir: Es muss einfach sein um erfolgreich zu sein...
Das Problem das die Typen geladen bleiben mit Bootstrapper lösen.
                    
                

25.02.2011

Timo Liebetrau

5 ● 1

Stelle deine .net-Frage jetzt!

Kontakt, Impressum, Lizenz, AGB