OK,

dies ist eine allgemeinere frage nach "hässlichen lebewesen in der ecke". Ich plane ein Projekt über WCF und PRISM zu starten. Ich habe einige Zeit mit PRISM rumgespielt, weiß und muss sagen, ich mag es. Solide Grundlage für Anwendungen mit guten Wachstumsmöglichkeiten.

Jetzt möchte ich WCF einbinden und eine verteilte Anwendung mit einem Teil auf einem Server und zwei auf den Clients erstellen. Je nach Szenario kann es sich sogar um dieselbe Maschine handeln oder auch nicht.

Meine Idee ist es nun, das Event-Konzept aus PRISM zu übernehmen und "over the wire" mit WCF und Callbacks zu erweitern, wie hier beschriebenWCF AlarmClock Callback Beispiel.

Ich habe ein kleines Bild erstellt, um die Idee zu veranschaulichen (hauptsächlich für mich), vielleicht macht dies die Dinge ein wenig klarer:

Die grauen Pfeile stehen für "using lib". Die WCF-Event-Base bedeutet normale PRISM-Ereignisse, bei denen die Publish-Methode "over the wire" genannt wird.

Es gibt ein paar Fragen, die mir in den Sinn kommen:

Gibt es bekannte Beispiele für solche Dinge?Was ist der beste Weg, um Ereignisse über das Netzwerk "auszulösen"?Mögliche Probleme mit diesem Konzept (die zuvor erwähnten hässlichen Tiere)

Bezüglich der zweiten Frage denke ich derzeit darüber nach, die Ereignisse mit einer Zeichenfolge (dem Typ des konkreten Ereignisses, das ich auslösen möchte) und der Nutzlast als Argument auszulösen. So etwas wiepublic void RaiseEvent(string eventType, object eventPayload){} Die Payload muss serialisierbar sein, vielleicht füge ich sogar einen Hashcheck hinzu. (Wenn ich beispielsweise ein Ereignis mit einem Bild als Argument zehnmal auslöse, übertrage ich das Bild nur einmal und verwende anschließend den Hash, damit der Server den Puffer beim Veröffentlichen verwendet.) ...

Ok, ich denke, Sie haben die Idee. Dieses "Ding" sollte sich wie eine riesige Einzelanwendung verhalten und eine Art vonWCF_EventAggregator anstelle des normalen PRISMIEventAggregator. (wow, beim Schreiben kam mir gerade die Idee, den IEventAggregator "einfach" zu erweitern, darüber muss man nachdenken) ...

Warum schreibe ich das? Nun, hauptsächlich für Feedback und um meine Gedanken zu sortieren. Also Kommentare willkommen, vielleicht etwas, worüber ich "vorsichtig" sein sollte?

Chris

[EDITS]

Client-Verteilung

Es sollte eine undefinierte Anzahl von Clients geben, der Server sollte keine Clients kennen. Der Server selbst kann ein Client für sich selbst sein und stark typisierte PRISM-Ereignisse in anderen Teilen des Quellcodes auslösen.

Der Hauptunterschied zwischen einem "Client" und einem "Server" ist die tatsächliche Implementierung des WCF_PRISM-Connectors, siehe nächstes Kapitel ...

Client Event Raising (PRISM-Funktion)

In PRISM benötigen Sie zum Auslösen einfacher Ereignisse nicht einmal einen Verweis auf eine Dienstschnittstelle. Der IEventAggregator kann über eine Abhängigkeitsinjektion abgerufen werden, die eine Instanz des gewünschten Ereignisses (z. B. WeatherChangedEvent) bereitstellt. Dieses Ereignis kann durch einfachen Aufruf ausgelöst werdeneventInstance.Publish (23) weil das Ereignis als implementiert istpublic class WeatherChangedEvent : CompositePresentationEvent<int>

WCF-PRISM-Anschluss

So einfach wie das Auslösen von Ereignissen ist das Abonnieren von Ereignissen. Jedes Modul kann Ereignisse mit der gleichen Technik abonnieren, eine Referenz erhalten und verwendenAbonnieren an dieses Ereignis anhängen.

Hier soll nun die "Magie" passieren. Die Clients werden ein Prisma-Modul enthalten, das für das Verbinden von PRISM-Ereignissen mit "wcf-Nachrichtensendungen" verantwortlich ist. Grundsätzlich werden alle verfügbaren Ereignisse in der Lösung registriert (sie sind ohnehin alle im Infrastrukturmodul definiert) und es wird eine WCF-Nachricht gesendet, falls ein Ereignis ausgelöst wird.

Der Unterschied zwischen einem SERVER und einem CLIENT ist die Implementierung dieses Moduls. Es muss aus zwei Gründen einen kleinen Unterschied geben.

Die WCF-Setup-EinstellungenDer Ablauf von Ereignissen, um eine Endlosschleife zu verhindern

Der Ereignisablauf ist (Beispiel)

Der Kunde erhält den Hinweis auf WeatherChangedEventwChanged.Publish (27) -> normales Auslösen von PRISM-EreignissenDas WCF_PRISM-Modul ist für event und abonniertSende dieses Ereignis an den ServerDer Server ruft intern die Instanz von WeatherChangedEvent ab und veröffentlicht sieDer Server ruft alle Clients zurück, die ihr WeatherChangedEvent auslösenOffene Punkte

Der naheliegende Punkt ist das Verhindern einer Schleife. Wenn der Server das Ereignis in ALLEN Clients auslösen würde, würden die Clients den Server zurückrufen, das Ereignis erneut auslösen usw. Es muss also ein Unterschied zwischen einem lokal verursachten Ereignis bestehen (was bedeutet, dass ich senden muss) es an den Server) und ein "Server verursachte Ereignis", was bedeutet, dass ich es nicht an den Server senden muss.

Wenn ein Client das Ereignis selbst initiiert hat, muss es nicht vom Server aufgerufen werden, da das Ereignis bereits ausgelöst wurde (im Client selbst, Punkt 2).

All dieses spezielle Verhalten wird im WCF-Ereignisauslösermodul zusammengefasst, das für den Rest der App unsichtbar ist. Ich muss mir überlegen, ob eine GUID oder ähnliches eine gute Idee ist, um zu wissen, ob die Veranstaltung bereits veröffentlicht wurde.

Und nun die zweite große Frage: Was wollte ich, als ich früher von "Streichern" erzählte? Ich möchte nicht jedes Mal, wenn ich ein Ereignis hinzufüge, eine neue Service-Interface-Definition schreiben. Die meisten Ereignisse in PRISM werden durch eine Zeile definiert, insbesondere während der Entwicklung möchte ich das WCF_Event_Raising_Module nicht jedes Mal aktualisieren, wenn ich ein Ereignis hinzufüge.

Ich dachte darüber nach, die Ereignisse direkt zu senden, wenn ich WCF anrufe, z. Verwenden einer Funktion mit einer Signatur wie:

public void RaiseEvent(EventBase e, object[] args)

Das Problem ist, ich weiß nicht wirklich, ob ich PRISM-Ereignisse so einfach serialisieren kann. Sie stammen alle von EventBase, aber ich muss dies überprüfen ... Aus diesem Grund hatte ich die Idee, den Typ (als Zeichenfolge) zu verwenden, da ich weiß, dass der Server das Infrastrukturmodul gemeinsam nutzt und eine eigene Instanz des Ereignisses abrufen kann (keine Notwendigkeit, es über das Kabel zu senden, nur das Argument)

Bis hierhin werde ich die Frage offen halten, um weitere Rückmeldungen zu erhalten. Wichtigste neue "Einsicht", die ich gerade bekommen habe: Muss über das Rekursions- / Endlosschleifenproblem nachdenken.

Btw. Wenn irgendjemand von all dem Ereignis-Gerede völlig verwirrt ist, probieren Sie es mit PRISM aus. Sie werden es lieben, auch wenn Sie nur DI und Events verwenden (RegionManager ist beispielsweise nicht mein Favorit)

Chris

[ENDE BEARBEITEN 1]