Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
SW Architektur und eigene AddIns
Sera
myCSharp.de - Member



Dabei seit:
Beiträge: 285

Themenstarter:

SW Architektur und eigene AddIns

beantworten | zitieren | melden

Zwecks Erweiterbarkeit sind AddIn Schnittstellen für die derzeit geplante Software (Host) im Gespräch. Da inkrementell entwickelt wird, gibt es verschiedene Meinungen für das frühzeitige Einfliessen der AddIn Struktur in das Grobkonzept.

Mittlerweile bin ich paar Tutorials durchgegangen und bin selbst der Meinung, daß sich AddIns nachträglich implementieren lassen (Interfaces only). Der Gegenpart ist eher der Meinung, daß im Falle eines nachträglichen Implementierens, das komplette Schnittstellenkonzept neu konzipiert und programmiert werden muss.

Hat jemand Erfahrung mit AddIn bzw Plug-In Programmierung und könnte bestätigen, daß diese nicht von der SW Architektur abhängig sind? Natürlich auch wenn ich falsch liegen sollte.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Sera am .
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

Erweiterungspunkte sind ein explizites Architekturmerkmal. Wenn du z.B. einen konkreten Typen in deinem Code verwendest ist diese Stelle nicht Plugin-tauglich. Aus dieser Sicht hat dein Kollege durchaus Recht.

Aber bei inkrementeller Entwicklung ist es immer eine Abwägung, ob man "potentielle" Erweiterungen in der Architektur vorsieht oder nicht. Wenn aber jetzt schon konkrete Anforderungen/Ideen bzgl. Plugins auf dem Tisch liegen, dann macht es natürlich Sinn, die notwendigen Änderungen zu berücksichtigen, auch wenn die konkrete Implementierung der Plugins später erfolgt. Zumindest lohnt sich eine Risikoabschätzung.
private Nachricht | Beiträge des Benutzers
Sera
myCSharp.de - Member



Dabei seit:
Beiträge: 285

Themenstarter:

beantworten | zitieren | melden

Erstmals Danke für die Antwort, svenson.

Wie definierst du "konkreten Typ" und dessen Untauglichkeit für Plug-In Implementierung?
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

Plugins zeichnen sich doch dadurch aus, dass die Funktionalität über Interfaces und nicht über Klassen angesprochen wird. Benutzt du in deinem Hauptprogramm also eine Klasse statt eines Interfaces ist dieser Code per se nicht Plugin-tauglich.

Wenn Funktionalität zur Laufzeit eingeschossen wird, z.B. über Plugins, Dependency Injection o.ä. dann sind Interfaces ein Muss.

Wenn die Plugins UIs anbieten ist dafür auch entsprechender Schmalz vorzusehen. Auch das Thema Serialisierung ist u.U. kritisch.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von svenson am .
private Nachricht | Beiträge des Benutzers
Andreas.May
myCSharp.de - Member

Avatar #avatar-2474.gif


Dabei seit:
Beiträge: 915

beantworten | zitieren | melden

Zitat von Sera
Erstmals Danke für die Antwort, svenson.

Wie definierst du "konkreten Typ" und dessen Untauglichkeit für Plug-In Implementierung?

Ein konkreten Typ wäre z.B. eine Klasse statt eines Interfaces.

Ich denke er meinte das es gut wäre vieles über Schnittstellen also Interfaces und intern so viel wie Möglich über Factory abzubilden, damit unabhängig von Typen bleibst.

[Edit] Da war er selber schneller,)
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Andreas.May am .
Wie vernichtet stand Andreas unter den flammenden Augen seiner Kunden.
Ihm war's, als stünde des Schicksals dunkle Wetterwolke über seinem Haupte X(
private Nachricht | Beiträge des Benutzers