Frage

Ich überlege, einen Teil unserer Anwendung in C# (derzeit veralteter VB6-Code) neu zu schreiben.Das Modul, mit dem ich beginne, ist für den Import von Daten aus verschiedenen Systemen in unsere Datenbank verantwortlich.Ungefähr fünf bis sechs Mal im Jahr bittet uns ein neuer Kunde, einen neuen Import für das von ihm verwendete System zu schreiben.Dies erfordert derzeit, dass wir für jede neue Importoption, die wir der Anwendung hinzufügen, eine neue Version unserer Software veröffentlichen.

Eines der Ziele der Neufassung besteht darin, dass die Anwendung Plug-Ins unterstützt.Jeder neue Import kann zu einer separaten Assembly werden, die von der Hostanwendung erkannt wird und dem Endbenutzer die Interaktion ermöglicht.Dies wird das Leben hoffentlich etwas vereinfachen, da wir einfach eine neue Assembly im Verzeichnis ablegen können und sie von der Hauptanwendung (Host) erkannt und verwendet wird.

Einer der Punkte, mit denen ich zu kämpfen habe, betrifft die Unterschiede zwischen den Importoptionen, die wir derzeit unterstützen.In einigen Fällen lassen wir den Benutzer tatsächlich auf ein Verzeichnis zeigen und alle darin enthaltenen Dateien in unser System einlesen.In anderen Fällen erlauben wir ihnen, auf eine einzelne Datei zu verweisen und deren Inhalt zu importieren.Darüber hinaus unterliegen einige Importe einer Datumsbereichsbeschränkung, die der Benutzer anwendet, während andere dies nicht tun.

Meine Frage ist: Wie kann ich die Anwendung so gestalten, dass sie eine gewisse Flexibilität bei den von uns erstellten und unterstützten Importen ermöglicht und gleichzeitig eine gemeinsame Schnittstelle implementiert, die es der Host-Anwendung ermöglicht, die Plug-Ins und Optionen leicht zu erkennen? dass jeder dem Benutzer ausgesetzt ist?

War es hilfreich?

Lösung

Ich würde Ihnen empfehlen, einen Blick auf das Managed Add-In Framework zu werfen, das mit .NET 3.5 geliefert wurde.Der Add-In-Team hat einige Beispiele und Tools unter gepostet CodePlex-Site sowie..

Andere Tipps

.Net 3.5 verfügt über den Namespace system.Addin.

Dieser Thread enthält auch einige gute Informationen für ältere Versionen des Frameworks:
Http://forums.devshed.com/net-development-87/system-plugin-532149.html

Für die Theorie werfen Sie einen Blick auf die Plugin-Muster in Martin Fowlers Patterns of Enterprise Application Architecture

Ein interessantes Beispiel finden Sie in diesem Tutorial: Plugin-Architektur mit C#

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top