Architekturproblem mit mehreren Anwendungen

Hallo Community!

Ich möchte mehrere Applikationen erstellen, die jeweils auf Teil-Komponenten (genauer gesagt Dialoge, Events und Klassen-Definitionen) der anderen Applikationen zugreifen sollen.

z.B. Soll Applikation A bei Drücken eines Buttons den Dialog XY der Applikation B aufrufen. Applikation B soll dafür jedoch nicht komplett gestartet werden. (ähnlich wie bei Office 2003 mittels Smart-Tags: Rechtsklick auf einen erkannten Namen -> E-Mail senden)

oder z.B.

Wenn in Applikation A ein Event ausgelöst wird (z.B. neuer Kontakt erstellt) soll die Applikationen B und C darüber informiert werden. Jedoch weiss Applikation A nicht welche anderen Applikationen die Events erhalten wollen, also fällt eine Benachrichtung Von Applikation A nach App. B und App. C aus. Stattdessen sollen die Applikationen die ein bestimmtes Event abfangen wollen, sich beim Eventhandler von A registrieren.

Welche Techniken werden benötigt um die zu realisieren und wie sollen die Klassen, Dialog, Events etc. aufgeteilt werden, um sie für andere Programme zugänglich zu machen?

Ist hier der Ansatz, von aussen zugängliche Komponenten für jede Applikation in eine eigene Dll zu packen, richtig? (Kann mir vorstellen dass die für Dialoge und Klassen geht, für Events stell ich mir das aber weniger realisierbar vor).

Bin für jede Art von Ratschlägen sehr dankbar.

Vielen Danke im Vorraus

DeveloperX

Für mich klingt das stark nach .Net-Remoting.

Du benötigst einen zentralen Service, bei dem sich die einzelnen Anwendungen für Ereignisse anderer Anwendungen registrieren können.

Der Service definiert auch das Kommunikationsprotokoll zwischen den Anwendungen. Man sollte vielleicht darauf achten, dass die Kommunikationswege in dem Service gebündelt werden und die Anwendungen nicht zu viel kreuz und quer selbst untereinander kommunizieren (siehe Mediator-Pattern). Das widerspricht allerdings wiederum der Modularität, also da muss gegeneinander abgewogen werden was wichtiger ist: zentrale Kontrolle/Übersicht oder Unabhängigkeit.

Ereignisse: Remoting und Ereignisse ist nicht ohne weiteres umsetzbar. Es gibt Probleme damit, dass der Type, der sich für ein Ereignis registriert, dem Ereignis-Halter-Type bekannt sein muss. Das ist natürlich sehr unschön, man kann z.B. keine neue Anwendung schreiben und diese für ein Ereignis einer bestehenden Anwendung registrieren. Es ist trotzdem möglich, indem man noch einen Proxy dazwischen hängt, der bekannt ist. Finde ich nicht so schön. Ohne Querelen geht es eigentlich nur mit dem Observer-Pattern (Listener-Interfaces, falls du Java kennst).

Ereignisse (oder Observer-Interfaces) und alle anderen für die Kommunikation erforderlichen Interfaces und Parameter-Typen müssen in öffentliche DLLs ausgelagert werden, die allen Anwendungen zur Verfügung stehen.

Zu den GUI-Klassen, die haben mit dem Ganzen nicht sehr viel zu tun. GUI-Klassen sind meiner Meinung nach immer lokal und nicht öffentlich (obwohl sie von MarshalByRefObject ableiten). Also: entweder ein Dialog wird in der einen oder der anderen Anwendung oder auch in beiden angezeigt. Die Anwendungen verwenden lokal die gleiche Dialog.dll (u.U. kopiert in verschiedene Ordner). Der Dialog ist aber auf keinen Fall öffentlich und remote zugreifbar/fernsteuerbar. Für sowas gibt es wie gesagt den Mediator.

Weil, es geht darum, einen Service nach außen bereitzustellen. Nicht darum, dass Clients von aussen in anderen Anwendungen "herumwurschteln" können wie sie lustig sind. So ein Lowlevel-Zugriff macht der Client-Anwendung keinen Spass (viel zu kompliziert) und die Server-Anwendung bringt es in echte Schwierigkeiten, weil sie nicht weiss wie ihr geschied (Vollzugriff, Bruch der Kapselung).

Gruss
Pulpapex

Hallo DeveloperX,

das hört sich auch für mich nach einer Art Services an, aber ich denke nicht, dass du da Remotes brauchst... es geht auch mit einer Art SendMessages/Notify über das ObserverPattern (z.B. im Buch von Head First Design Patterns beschrieben) oder mach Dir eine Art IControlServices wie in C-Sharp

lies Dir dazu bitte http://www.apress.com/free/content/Dissecting_A_CSharp_Application.pdf

durch (dissecting a c# application, komplett in English)

Vielen Dank für deinen ausführlichen Beitrag Pulpapex!

Klingt ordentlich intressant und hat mir auch sehr weitergeholfen. Mir ist jetzt einiges klar, über das was ich vorhabe zu entwickeln. Vor allem das, dass die Dialoge nicht öffentlich zugreifbar sind hat mich sehr weitergebracht. Ich kenne zwar das Observer-Pattern (aus Java-GUIs) sehr gut, ist mir jedoch nicht in den Sinn gekommen das hier verwenden zu können, vermutlich deswegen weil ich es ja immer nur innerhalb einer Applikation verwendet habe ... das Stichwort "Mediator" kannte ich in diesem Zusammenhang noch nicht...

Überhaupt ist dein gesamter Beitrag sehr hilfreich. Echt spitze! Vielen Dank nochmals!!

Mit freundlichen Grüßen
DeveloperX

Edit: Auch dir vielen Dank für den Tipp, dr4g0n76. Werd gleich mal das PDF unter die Lupe nehmen!

@dr4g0n76:
Remoting heisst ja nicht wirklich remote auf verschiedenen Rechnern und über TCP. Lokal läuft das glaube ich über COM oder COM+. Und wenn es ums Programmieren geht, ist Remoting auch einfacher als Windows-Botschaften. Im besten Fall hat man bekannte Services in der App.Config eingetragen. Dann reicht ein new MyService(), um die Verbindung herzustellen. Es gibt (fast) keine Unterschiede beim Zugriff auf lokale und entfernte Objekte (fast wegen den Ereignissen z.B.).

Andererseits habe ich von Windows-Botschaften nicht die Ahnung. Den Link habe ich mir jetzt auch nicht mehr angeschaut. Mache ich morgen mal.

Gute Nacht,
Pulpapex

@pulpapex:

Ja ich weiss, Ich versteh nur nicht, warum ihr denkt, dass man dafür schon RemoteServices einrichten müßt. Das geht mit ganz normaler Windows-Message Benachrichtigung... selbst die Event-handler sind ja schon da...

unter C++ bzw. C (geht ja in C# auch, per WinAPI) hätte man das ganze auch mit SendMessage/PostMessage usw. lösen können.

@DeveloperX:
Ausserdem, ich weiss ja nicht wie Dein Programm aussieht, aber eine weitere Möglichkeit, alle zu dezentralisieren und vereinheitlichen nennst Du eigentlich schon selber. Du könntest also alles, an das Botschaften egal ob von Anwendung A, B, C geschickt werden / bzw. empfangen werden soll in eine Komponente auslagern, dann müssen die Anwendungen A, B, C "nur" noch eine Referenz auf die Komponente haben und "schon" läuft das ganze.

"z.B. Soll Applikation A bei Drücken eines Buttons den Dialog XY der Applikation B aufrufen. Applikation B soll dafür jedoch nicht komplett gestartet werden."
Das lässt sich über Reflection lösen, App A muss allerdings von B wissen wo die Assemblys liegen. Remoting ist dem Fall schwer wenn B garnicht läuft.

Hallo ikaros!

Wenn ich aber den Dialog in eine dll packe und der Dialog die ganze Arbeit, sprich Datenbank-Zugriffe löst, müsste es jedoch funktionieren, oder?

mfg DeveloperX

Ja

Original von DeveloperX

Wenn ich aber den Dialog in eine dll packe und der Dialog die ganze Arbeit, sprich Datenbank-Zugriffe löst, müsste es jedoch funktionieren, oder?

Die GUI sollte NIEMALS direkrte Datenbankzugriffe machen! Zugriff auf Datenquellen und Implementierung von Domänenlogik sollte immer in einer autonomen Mittelschicht stattfinden. Die GUI sollte nur Code zur Anzeige und Benutzerinteraktion enthalten. Bei steigender Benutzerzahl kann die Mittelschicht auf Applikationsserver ausgelagert werden. Wenn alles mit den Forms verwurstelt ist, geht das nicht. Außerdem ist die eigentliche Funktionalität einer Anwendung an einer Stelle. Das erleichtert Wartung und Erweiterung.

Eine sauber Entwickelte Mittelschicht lässt sich auch als API von anderen Anwendungen aus nutzen.

Schau Dir mal folgenden Architekturvorschlag an: