Dobrze,

jest to bardziej ogólne pytanie „brzydkie stworzenia w rogu”. Planuję rozpocząć projekt na WCF i PRISM. Od jakiegoś czasu dobrze się bawię z PRISM i muszę powiedzieć, że to lubię. Solidne podstawy do zastosowań z przyjemnymi możliwościami wzrostu.

Teraz chcę włączyć WCF i zbudować aplikację rozproszoną, z jedną częścią na serwerze i dwiema na klientach. Może to być nawet ta sama maszyna, lub nie, w zależności od scenariusza.

Moim pomysłem jest teraz przejąć koncepcję zdarzeń z PRISM i rozszerzyć ją „za pomocą drutu” za pomocą WCF i wywołań zwrotnych, jak opisano tutajPrzykład wywołania zwrotnego alarmu WCF.

Stworzyłem mały obrazek, aby zilustrować ten pomysł (głównie dla mnie), być może to sprawia, że ​​rzeczy są bardziej jasne:

Szare strzałki oznaczają „korzystanie z lib”. Baza zdarzeń WCF oznacza normalne zdarzenia PRISM, gdzie metoda publikowania jest nazywana „over the wire”.

Jest kilka pytań, które przychodzą mi do głowy:

Czy istnieją jakieś znane przykłady takich rzeczy?Jaki będzie najlepszy sposób na „podnoszenie” wydarzeń w sieci?Jakiekolwiek możliwe problemy z tą koncepcją (wspomniane wcześniej brzydkie stworzenia)

Jeśli chodzi o drugie pytanie, obecnie myślę o podniesieniu zdarzeń za pomocą łańcucha (typu konkretnego zdarzenia, które chcę podnieść) i ładunku jako argumentu. Coś jakpublic void RaiseEvent(string eventType, object eventPayload){} Ładunek musi być dostępny do serializacji, być może nawet dołączam hashcheck. (Oznacza to, że jeśli podniosę np. Zdarzenie z obrazem jako argument 10 razy, to przeniesie obraz tylko raz, a następnie użyje skrótu, aby umożliwić serwerowi użycie bufora podczas publikowania) ...

Ok, myślę, że masz pomysł. Ta „rzecz” powinna zachowywać się jak gigantyczna pojedyncza aplikacja, używając pewnego rodzajuWCF_EventAggregator zamiast normalnego PRISMIEventAggregator. (wow, pisząc, wpadłem na pomysł, aby „po prostu” rozszerzyć IEventAggregator, muszę to przemyśleć) ...

Dlaczego to piszę? Cóż, głównie w celu uzyskania opinii i uporządkowania myśli. Tak więc komentarze są mile widziane, może o czymkolwiek powinienem być „ostrożny”?

Chris

[EDITS]

Dystrybucja klienta

Powinna istnieć nieokreślona liczba klientów, serwer nie powinien być świadomy klientów. Sam serwer może być klientem dla siebie, wywołując silnie wpisane zdarzenia PRISM w innych częściach kodu źródłowego.

Główną różnicą między „klientem” a „serwerem” jest rzeczywista implementacja złącza WCF_PRISM, patrz następny rozdział ...

Podnoszenie zdarzeń klienta (funkcja PRISM)

W PRISM, aby podnosić proste zdarzenia, NIE potrzebujesz nawet odniesienia do interfejsu usługi. IEventAggregator można uzyskać poprzez wstrzyknięcie zależności, zapewniając wystąpienie żądanego zdarzenia (np. WeatherChangedEvent). To wydarzenie można podnieść, po prostu dzwoniąceventInstance.Publish (23) ponieważ zdarzenie jest realizowane jakopublic class WeatherChangedEvent : CompositePresentationEvent<int>

WCF - Złącze PRISM

Proste jak podnoszenie wydarzeń jest subskrybowanie wydarzeń. Każdy moduł może przypisać zdarzenia za pomocą tej samej techniki, uzyskując referencję i używającSubskrybować dołączyć do tego wydarzenia.

Oto miejsce, w którym „magia” powinna się wydarzyć. Klienci będą zawierać moduł pryzmatyczny odpowiedzialny za łączenie zdarzeń PRISM z „wysyłaniem wiadomości wcf”. Zasadniczo będzie on zawierał wszystkie dostępne zdarzenia w rozwiązaniu (wszystkie są zdefiniowane w module infrastruktury) i wysyła komunikat WCF na wypadek wystąpienia zdarzenia.

Różnica między SERWEREM a KLIENTEM polega na implementacji tego modułu. Musi być niewielka różnica ze względu na dwie rzeczy.

Ustawienia konfiguracji WCFPrzepływ zdarzeń, aby zapobiec nieskończonej pętli

Przepływ zdarzeń będzie (przykład)

Klient otrzymuje ref do WeatherChangedEventwChanged.Publish (27) -> normalne podnoszenie zdarzeń PRISMModuł WCF_PRISM subskrybuje zdarzenie iwyślij to zdarzenie na serwerSerwer wewnętrznie pobiera wystąpienie WeatherChangedEvent i publikujeSerwer oddzwania do wszystkich klientów podnoszących ich WeatherChangedEventPunkty otwarte

Oczywistym punktem jest zapobieganie pętli. Jeśli serwer podniósłby zdarzenie u WSZYSTKICH klientów, klienci oddzwoniliby na serwer, ponownie wywołując zdarzenie itd. Musi więc istnieć różnica między zdarzeniem wywołanym lokalnie (co oznacza, że ​​muszę wysłać na serwer) i „zdarzenie spowodowane przez serwer”, co oznacza, że ​​nie muszę go wysyłać na serwer.

Ponadto, jeśli klient sam zainicjował zdarzenie, nie musi być wywoływany przez serwer, ponieważ zdarzenie zostało już wywołane (w samym kliencie, punkt 2).

Wszystkie te specjalne zachowania zostaną zawarte w module wywoływania zdarzeń WCF, niewidocznym dla reszty aplikacji. Muszę pomyśleć o tym, „jak się dowiedzieć, czy wydarzenie już zostało opublikowane”, być może dobrym pomysłem będzie identyfikator GUID lub coś takiego.

A teraz drugie duże pytanie, do czego dążyłem, mówiąc wcześniej o „strunach”. Nie chcę pisać nowej definicji interfejsu usługi za każdym razem, gdy dodam zdarzenie. Większość zdarzeń w PRISM jest definiowana przez jedną linię, zwłaszcza podczas opracowywania Nie chcę aktualizować modułu WCF_Event_Raising_Module za każdym razem, gdy dodam zdarzenie.

Myślałem o wysłaniu zdarzeń bezpośrednio podczas wywoływania WCF, np. korzystanie z funkcji z podpisem, takiej jak:

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

Problem polega na tym, że tak naprawdę nie wiem, czy mogę łatwo serializować zdarzenia PRISM. Wszystkie one wywodzą się z EventBase, ale muszę to sprawdzić ... Z tego powodu wpadłem na pomysł użycia typu (jako łańcucha), ponieważ wiem, że serwer współużytkuje moduł infrastruktury i może uzyskać własne wystąpienie zdarzenia (nie ma potrzeby wysyłania go przez przewód, tylko arg)

Do tej pory pozostanę otwarte, aby uzyskać więcej informacji zwrotnych. Główny nowy „wgląd”, który właśnie dostałem: Muszę pomyśleć o problemie pętli rekurencyjnej / infite.

Btw. jeśli ktokolwiek jest całkowicie zdezorientowany rozmową o tym wydarzeniu, spróbuj PRISM. Pokochasz to, nawet jeśli używasz tylko DI i Events (np. RegionManager nie jest moim ulubionym)

Chris

[KONIEC EDYCJI 1]