WCF, a dobre zachowanie
Pod tym enigmatycznym nieco tytułem kryje się notka na temat problemu wymuszania różnego rodzaju zachowania po drugiej stronie łącza między dwoma systemami.
O co chodzi? Wyobraźmy sobie dwie aplikację. Pierwsza z nich, nazwana przeze mnie umownie Klientem, chce do drugiej aplikacji (nazywanej dalej Serwerem) przekazać zachowanie. Nie dane, ale zachowanie. To znaczy nie
przetwórz mi tę porcję danych
ale raczej
wykonaj taką operację lub zrealizuj taki algorytm.
Po co w ogóle rozwiązywać taki wydumany problem? Ano, nie jest on taki wydumany. Wyobraźmy sobie, że Klient i Serwer to systemy, które operują na tych samych danych biznesowych. Klient dane produkuje (lub edytuje), natomiast Serwer utrzymuje sobie kopię tylko-do-odczytu. Jeśli systemy te nie są oddalone, możemy rozwiązać problem np. współdzieląc jedną bazę danych lub replikując jedną bazę do drugiej. Jeśli jednak są one geograficznie i politycznie oddalone, jedynym rozsądnym rozwiązaniem wydaje się przesyłanie przed Klienta do Serwera “po kablu” komend aktualizujących dane. Komend, czyli zachowań.
Specyfiką przesyłania zachowania jest fakt, że Klient decyduje o rodzaju wykonywanej operacji oraz o jej argumentach, natomiast sama konkretna implementacja algorytmu jest własnością Serwera. Dzięki temu niuansowi nie jest możliwe przesłanie (np. Remoting-iem) obiektu komendy (wzorzec Command) w klasycznym rozumieniu. Klient musiałby bowiem wtedy posiadać wiedzę o strukturze serwera (ponieważ on instancjonawałby obiekty komend zawierające algorytmy).
Zastanawiając się nad tym, który z wzorców znanych ze swej użyteczności w problemach komunikacji, wykorzystać możemy przypomnieć sobie o Wizytatorze. Zdefiniowanie interfejsu wizytatora w tym samym, współdzielonym między Serwerem, a Klientem assembly, które zawiera klasy komunikatów , nic nas nie kosztuje w kontekście coupling-u. Implementacja interfejsu znajduje się wyłącznie po stronie serwera, więc z tym też nie ma problemu. Jedynym minusem jest fakt, że dodanie nowego komunikatu powoduje konieczność rozbudowy wizytatora o nową metodę. I tak za każdym razem.
Ale jest też inne rozwiązanie. Wykorzystuje ono fakt, że mamy do czynienia z granicą międzyprocesową oraz, ja się zapewne domyślacie z tytułu, WCF-a. Chociaż WCF to za dużo powiedzianie. Generalnie chodzi o DataContractSerializer i jego pojęcie równoważności typów (data contract equivalence). W skrócie, oznacza ono, że dopóki serializowany i deserializowany typ są reprezentowane przez identycznie wyglądający schemat, dopóty możliwe jest wysyłanie obiektów jednego typu, a odbieranie – drugiego.
Jak to się ma do naszego problemu? Ano tak, że możemy mieć po stronie Klienta i po stronie Serwera dwa równoległe zestawy klas komend. Klasy te parami będą nazywać się tak samo oraz zawierać te same pola danych. Różnica polegać będzie jedynie na tym, że klasy po stronie Serwera będą zawierać zachowanie, które ma zostać wykonane po odebraniu. Aby nie kopiować kodu, oba zestawy klas mogą dziedziczyć z trzeciego, którego klasy definiowałyby sam zakres danych przekazywany w komendach. Unikniemy dzięki temu duplikacji kodu. Dodatkowo, jeśli po stronie Klienta komendy nie mają w ogóle zachowania, można ich w ogóle nie tworzyć tylko polegać na współdzielonych klasach definiujących dane.
W tym wypadku, logicznie, to serializacja zapewnia nam mechanizm mapowania kontenerów na dane na zachowanie z nimi związane.
Stąd możecie pobrać solution VS, które zawiera aplikację demonstrującą to podejście. Zaimplementowany przykład zawiera komendy, które mają zachowanie zarówno po stronie Klienta, jak i Serwera.
