Minimalistisches PlugIn-System

[DeddyH]

Ich trage mich mit dem Gedanken, ein kleines dynamisch erweiterbares Programm zu schreiben. Dazu habe ich mir bislang Folgendes überlegt:
- PlugIns liegen in Form von DLLs vor, welche eigentlich komplette Mini-Anwendungen sind
- diese liegen in einem fest definierten Verzeichnis
- beim Programmstart durchsucht die Hauptanwendung dieses Verzeichnis nach DLLs
- jede gefundene wird daraufhin überprüft, ob sie klar festgelegte Routinen exportiert
- falls dem so ist, wird sie einer Liste hinzugefügt und per Menü o.ä. zur Verfügung gestellt

Meine Frage dazu: ist das so machbar oder denke ich zu simpel? Welche Gefahren könnten u.U. lauern?
Dank im Voraus für Tipps und Anregungen.

[Phoenix]

Das Prinzip funktioniert so ohne weiteres.
Allerdings klingt das zwar Simpel, aber der Teufel steckt im Detail (konkret: das Design Deiner 'klar festgelegten Routinen' bzw. die Kommunikation zwischen dem Plugin und dem Hauptprogramm). Das ganze ist also durchaus Aufwändiger als man anfangs denkt.

[DeddyH]

Naja, mir ist schon klar, dass ich diese festgelegten Routinen nach Möglichkeit so definieren muss, dass später keine mehr dazukommen müssen. Aber bislang ist das Ganze ja eh nur ein Gedankenspiel, ich werde schon merken, wo ich mir wieder selbst ein Bein stelle

Danke für Deine Antwort

[ele]

Klingt ganz vernünftig.

Wenn dein Programm einfach alle DLLs in einem Verzeichnis versucht zu laden, muss man, um ein Plugin zu deaktivieren, das Plugin aus dem Verzeichnis herauskopieren oder umbenennen. Das ist je nach dem etwas umständlich, aber durchaus kein Blocker.

Bei Plugin-Systemen besteht ganz allgemein die Gefahr, dass die Plugin-Schnittstellen nicht genügend durchdacht werden. Das im Nachhinein zu ändern kann u.U. sehr mühsam sein (neu kompilieren aller Dlls), vorallem dann, wenn Dritthersteller anfangen Plugins beizusteuern.

Aus diesem Grund fände ich es wichtig ein System zu haben, dass dir die Version des Plugins (bzw. der Pluginschnittstelle) mitteilt. Dann kannst du notfalls eine Fehlermeldung ausgeben, falls eine Version von einem Plugin dagerkommt, dass dein Programm nicht unterstützt. Ich benutze in diesem Zusammenhang übrigens die Möglichkeit in der Versions-Information des Programmes (oder in diesem Fall DLL) einen neuen Schlüssel zu erstellen (z.B. PluginVersion).

[DeddyH]

Sehr guter Einwand. Ich glaube zwar kaum, jemals in den Genuss zu kommen, dass sich ein Dritthersteller für meine Progrämmchen interessiert, trotzdem sollte man so etwas gleich am Anfang mit bedenken.

[ele]

Der "Dritthersteller" kann manchmal auch ein Alter Ego aus der Vergangenheit sein...

[Stevie]

DLL basierte Plugin Systeme haben immer das Problem, dass man sehr schlecht komplexe Daten (Objekte) austauschen kann. Forms und Frames aus DLLs sind auch immer anfällig für Ärger. Dafür braucht man dann wieder BPLs, gegen die dein Programm und die Plugins gelinkt sind. Auch stellt sich die Frage, wieviel Wissen steckt in den Plugins? Stichwort Menü: hängen die Plugins sich selber da rein, weil sie das Menü übergeben bekommen (nicht gut) oder geben sie bloß eine Liste der Aktionen und die Anwendung hängt sie an. Wie stellt die Anwendung fest, wo sie hinkommen?

DSharp hat übrigens auch einige Units, mit denen man mit wenigen Handgriffen ein Plugin System bauen kann (angelehnt an MEF)

[gsh]

Ich hab vor langer langer Zeit mal einen Codelib beitrag für ein kleines Plugin System geschrieben, vielleicht bringt dich das auf Ideen:
http://www.delphipraxis.net/73567-fl...ginsystem.html
Die Diskussion dazu ist auch recht interessant:
http://www.delphipraxis.net/74448-fl...iskussion.html

[mschaefer]

Das Problem mit en PlugIn-Systemen ist, dass es meist Insellösungen sind. Um das vom Zeitaufwand in den Griff zu bekommen habe ich dies auch mit eigenständigen Anwendugen gemacht, die nur mit einem versteckten Aufrufparameter starteten. Der Datenaustausch läuft über xml-Files. Es war angedacht es über einen zentraln SOAP-Server zu steuern, aber dazu ist es nie gekommen. Also kurzum, ist ein gangbare Weg aber nicht der Weisheit letzter Schluß.

Grüße

[FredlFesl]

Hi,

Ich habe mal Folgendes gemacht (alles so wie dein Vorschlag, also Verzeichnis durchsuchen, DLL laden usw.):
Jede DLL exportiert neben den Prozeduren "GetName" und "Initialize" (dazu später) beliebige Prozeduren.
Das Einzige, was diese beliebigen Prozeduren gemein haben, ist die Schnittstelle, denn sie sehen alle so aus:

Procedure SomeDLLProcedure (inParam : OleParam, var result, outParam : OleParam);

Ein- und Ausgabeparameter können also Arrays, Streams oder was auch immer sein. Result ist entweder unassigned oder enthält einen Fehler (gestreamed).

Aufgerufen wurden die über einen Plugin-Manager. Nehmen wir an, wir haben eine DLL "MyDLL" und die hat die Prozeduren "Proc1" und "Proc2". Dann rufe ich eine Prozedur der DLL so auf:
ThePluginManager.Call ('MyDLL.Proc1', inParam, result, outParam);

Ich habe damit also eine allgemeine Schnittstelle, die ich beliebig erweitern kann.
Der Plugin-Manager ist auch für die Kommunikation zwischen den DLL verantwortlich, denn er übergibt der DLL per exportierter 'Initialize' Prozedur eine Callback-Schnittstelle, sodaß auch ein Plugin über die gleiche -eben beschriebene Schnittstelle- ein anderes Plugin aufrufen kann. Oder definierte Routinen der Hauptanwendung..

Bei mir gab es in dem Sinne keine Hauptanwendung, denn die DLL implementierten einen Webservice, wobei die einzelnen 'Anwendungen' eben diese DLLs waren.

Desweiteren habe ich dafür gesorgt, das die DLL zur Laufzeit ausgetauscht werden können, ohne die Anwendung (den Service) beenden zu müssen. Die neue oder auszutauschende DLL kann man per TCP direkt in den Service impfen. Der packt die DLL in das Plugin-Verzeichnis, entfernt die alte Version und ab einem definierten Zeitpunkt werden alle Aufrufe an die neue DLL geleitet.

War ziemlich cool und hat auch gar nicht mal so viel Code.