Software mit PlugIns, möglich?

  • VB.NET
  • .NET (FX) 4.0

Es gibt 22 Antworten in diesem Thema. Der letzte Beitrag () ist von Vainamo.

    Natürlich implementiert das Plugin die ganze Logik selbst, braucht es aber nicht direkt ins Control zu machen, du hast quasi nen ganz normales autarkes projekt und haust am Ende noch ne Implementierung von dem Interface dazu, dass dann dein Hauptcontrol erstellt, du kannst also trotzdem weiterhin MVC normale formulare oder sonst was machen.

    Und wie gesagt, wenn es halt nicht autark sein soll, dann brauchst du halt irgendwelche Klar definierten Schnittpunkte, zum verallgemeinern, sonst kann man das ja nicht allgemein machen. Ansonsten vlt. noch shared project?
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    Acr0most schrieb:

    Es geht mir lediglich ums Verständnis.
    Also:
    Ein Hauptprogramm habe eine Kamera- und eine Druckerschnittstelle (Spezialdrucker: Label oder Etiketten oder so).
    Per Plugin sollen (nahezu) beliebige Kameras und Drucker angesteuert werden können.
    Da bietet sich je ein Interface an, ICamera und IPrinter.
    Zu überlegen ist, ob Kameras und Drucker ein gemeinsames Basisinterface IHardware implementieren sollten.
    Wenn diese Überlegungen klar sind, kann man so vorgehen:
    IHardware:
    • IDisposable zur Bereinigung nicht gemanageder Ressourcen
    • Initialisierung
    • Selbsttest
    • TransferParameter
    • Quit
      usw.
    ICamera:
    • bool IsColorCamera
    • int Width, Height
    • int BitPerPixel
      usw.

    Diese Prozeduren / Properties müssen dann bei allen Exemplaren ausgefüllt werden.
    Und wenn der durchaus übliche Zustand eintritt, dass eine neue Kamera / Drucker Eigenschaften hat, die die vorhandenen nicht hatten, muss das Interface erweitert werden.
    Gut wäre dann, ein HasXyzProperty-Flag zu implementieren oder ein Spezialinterface, z.B. ISpecialXyzCamera, was man dann durch Casten ermitteln kann.
    Vorteil des Interfaces ISpecialXyzCamera: Du musst nur die neuen Kameras anfassen und das Hauptprogramm.
    Nachteil: Du musst bei jeder neuen Property den Interface-Cast durchführen.
    Das ist dann abzuwägen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich habe für meinen Chat auch ein Extension System erstellt.
    Im Wesentlichen brauchst du 2 Teile. Ein Interface das festlegt, wie eine Extension aufgebaut sein muss und eine Gegenstelle mit der die Extension kommunizieren kann.
    In meinem Chat sind das das Interface IExtension und die Interfaces IServer und IClient.

    Wenn man nun eine Extension erstellt, kann mit Hilfe der Interfaces auf Funktionen des Hauptprogramms zugegriffen werden (z.B. Nachrichten versenden oder Channel erstellen) aber es können auch z.B. Forms angezeigt werden. Im Gegenzug kann der Server beziehungsweise der Client mit Hilfe des IExtension Interfaces auf die Funktionen der Extension zugreifen und ihr so mitteilen, wann sie gestartet wurde, in welchem Ordner sie ihre Daten ablegen darf etc. Auch ein Event System ist so möglich, sodass die Extension Events abonieren kann und so z.B. mitbekommt, dass ein neuer User gejoint ist.

    Die fertigen Extensions werden dann als Klassenbibliotheken in einen festgelegten Ordner gepackt und von dort lädt das Hauptprogramm dann diese mittels Reflection.
    Im Falle meines Chats geschieht dies so: github.com/defectively/defecti…ement/ExtensionManager.cs.

    Grüße
    Vainamo