Realisierung einer Plugin-fähigen 3-Schichten-Architektur
Hallo Zusammen,
ich plane zurzeit ein Projekt, welches größtenteils darauf basiert, das Komponenten verschiedener Hersteller in einer mehrschichtigen Architektur zusammenarbeiten können. Somit müssen PlugIns in einem Basisframework auf mehreren Ebenen zusammenarbeiten.
Die einzelnen Schichten der geplanten Architektur sind eine Persitierungsschicht, eine Logikschicht (welche die gesamte Geschäftslogik enthält) und eine Präsentationschicht, welche mit der Logikschicht über Webservices kommuniziert.
Meine Frage ist nun, ob es für so etwas schon Projekte oder Ansätze zur Realisierung gibt. Ich habe viel über Plugins, MEF, etc. gelesen, jedoch interessiert mich weniger, wie ich eine Anwendung generell „erweiter“ kann, sondern viel mehr ein ganzheitlicher Ansatz, der mir zeigt, wie ich eine Erweiterbarkeit über mehrere Schichten realisiere.
Vielen Dank erstmal.
Hallo meisteralex,
Somit müssen PlugIns in einem Basisframework auf mehreren Ebenen zusammenarbeiten.
kannst du mal ein, zwei Beispiel bringen, welche Art von ebenenübergreifender Zusammenarbeit dir da vorschwebt?
herbivore
Wenn du eine AddIn / PlugIn Architektur planst in der du viele Fremdkomponenten nutzt
ist wahrscheinlich MAF das richtige für dich:
Erzeugt zwar im Vergleich zu MEF ziemlich viel Overhead, ist dafür aber auf Robustheit & Security ausgelegt.
kannst du mal ein, zwei Beispiel bringen, welche Art von ebenenübergreifender Zusammenarbeit dir da vorschwebt?
Da gibt es unzählige. Nehmen wir z.b. an du hast ein Basis-CMS-System, welche du um eintsprechnede Komponenten erweitern willst. Das Basis-CMS läuft auf einer 3-Schichten-Architektur. DAs Add-In muss sich somit auch durch alle 3 Schichten ziehen.
@Joetempes: Das Managed AddIn Framework mag zwar eine gute allgemeine Lösung für AddIn-Architekturen sein, nur hat es nichts mit mehrschichtigen Architekturen zu tun.
Hallo,
Das Basis-CMS läuft auf einer 3-Schichten-Architektur. DAs Add-In muss sich somit auch durch alle 3 Schichten ziehen.
ich verstehe hier auch nicht, wieso ein AddIn vom Datenzugriff bis zur GUI alle Ebenen brauch.
mfg
serial
Nehmen wir an, wir haben das Basis-CRM-System und wollen es um eine Komponenten erweitern, welche es z.B. ermöglicht, zu den gepflegten Kunden Dokumente abzulegen. Hierzu muss sowohl auf visueller Ebene (PresentationTier), als auch auf logischer Ebene (ApplicationTier), sowie auf der Ebene zur Datenspeicherung Code eingefügt werden.
Wenn dein ApplicationTier WebServices oder ähnliches sind (WCF, Restful, etc.) kannst du diese mittels AddIn eigentlich nicht erweitern, denn dann würden sich die Contracts ändern und alles muss angepasst werden. Das AddIn müsste also einen komplett eigenständigen ApplicationTier mit sich bringen. Damit fällt die Schicht aus der Erweiterbarkeit eigentlich raus. Der DataTier wird schätze ich mal direkt ein SQL Server oder ähnliches sein. Das einzige was also wirklich erweiterbar sein müsste, ist die GUI. Und da gibt es MAF, MEF, und wie sie alle heißen. Wobei ich eher MEF als MAF nehmen würde.
Aber um das alles zu beurteilen, müsste man genauer wissen wie deine Architektur aufgebaut ist. Bei AddIns gibt es kein Königsweg. Sowas muss 100% zur Architektur passen.
"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)