Struktura aplikacji za pomocą WCF
Mam aplikację WPF, która do tej pory była tylko klientem, ale teraz pracuję nad podzieleniem jej na stronę klienta i serwera. W tej pracy przedstawiam WCF do komunikacji klient-serwer. Moja aplikacja ma kilka projektów, a referencje serwisowe są potrzebne z więcej niż jednego z nich.
Początkowy wysiłek w robieniu separacji polega na robieniu wszystkiego "prosto do przodu". Wszystkie projekty, które muszą komunikować się z usługą, otrzymują referencję serwisową, podobnie jak główny WPF projekt aplikacji - aby uzyskać aplikację.config tam. Uważam, że to szybko zamienia się w bałagan i nie mogę sobie wyobrazić, że jest to typowa Architektura, z której ludzie korzystają? Widziałem również problemy z tym, że każda z referencji usługi generuje nową implementację klas DataContract - stąd nie ma wspólnego zrozumienia klas DataContract na cross of projects. Mam kilka klas ViewModel w jednym projekcie, a inny projekt instanciating jakiś ViewModel. Chciałbym przekazać obiekt otrzymany z usługi, ale nie mogę, ponieważ wygenerowana reprezentacja po stronie klienta otrzymanego obiektu różni się w każdym projekcie.
Więc - czy istnieje zalecany sposób strukturyzowania takich separacji klient / serwer przy użyciu WCF? Czy zasady do naśladowania? Myślę o jednym wspólnym projekcie Proxy używanym po stronie klienta, który zajmuje się komunikacją z usługami, owija otrzymane dane i zwraca dane w formie dobrze znanej bibliotekom klienta. Powinien dać tylko jedną usługę Referencja, i chyba potrzebuję tylko aplikacji.config w wpfApp-project? Czy to ma sens?
3 answers
Lubię układać swoje rozwiązania WCF TAK:
Contracts (class library)
Zawiera wszystkie umowy dotyczące usług, operacji, usterek i danych. Może być współdzielony między serwerem a klientem w czystej postaci .NET-to-.NET scenariusz
Implementacja Usługi (Biblioteka klas)
Zawiera kod do implementacji usług i wszelkie metody wsparcia / pomocy potrzebne do osiągnięcia tego celu. Nic więcej.
Service host(s) (opcjonalnie - może to być Winforms, konsola App, NT Service)
Zawiera hosty usługowe do debugowania/testowania lub ewentualnie również do produkcji.
To w zasadzie daje mi serwerową stronę rzeczy.
Po stronie klienta:
Client proxies (class library)
Lubię pakować klienckie serwery proxy do osobnej biblioteki klas, aby mogły być ponownie używane przez wiele rzeczywistych aplikacji klienckich. Można to zrobić za pomocą svcutil lub "Add Service Reference" i ręcznie poprawiając wynikającą aplikację.config ' s, lub wykonując ręczną implementację proxy klienta (podczas współdzielenia assembly kontraktów) przy użyciu konstruktów ClientBase<T> LUB ChannelFactory<T>.
1-n rzeczywisty klient (dowolny typ aplikacji)
Zazwyczaj odwołuje się tylko do zespołu serwerów proxy klienta, a może także do zespołu kontraktów, jeśli jest współdzielony. Może to być ASP.NET, WPF, Winforms, aplikacja konsolowa, inne usługi - ty to nazwij.
W ten sposób; mam ładny i czysty layout, używam go konsekwentnie w kółko i naprawdę myślę dzięki temu mój kod jest czystszy i łatwiejszy w utrzymaniu.
To było zainspirowane przez Miguela Castro Extreme WCF screen cast Na DotNet Rocks TV z Carlem Franklinem-Gorąco polecam screen cast !Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-11 13:45:57
To zależy. WCF jest dużym frameworkiem i ma obejmować wiele różnych scenariuszy.
Ale dla prostej aplikacji jak twoja, kiedy nie dbasz o rzeczy takie jak Java interop lub generic web services interop, to jest to, co robię:
Wszystkie klasy DataContract i interfejsy ServiceContract trafiają do biblioteki (lub bibliotek) współdzielonej między Klientem a serwerem. Zauważ, że prawdopodobnie nie powinieneś udekorować swojej realizacji usług ServiceContract, można utworzyć osobny interfejs z atrybutami ServiceContract, które można umieścić we wspólnym złożeniu.
Wygląda na to, że wszystko robisz właściwie. To, czego prawdopodobnie nie potrzebujesz, to automatyczne generowanie proxy w ogóle w tym przypadku. To tylko sprawia Ci ból. Dlatego nie używaj okna dialogowego Dodaj odniesienie do usługi do tego, co robisz. Wystarczy dołączyć współdzielone zestawy DataContract i użyć ChannelFactory, aby uzyskać serwer proxy do zdefiniowanego interfejsu usługi w bibliotece współdzielonej. Dzięki temu nie musisz ponownie generować serwera proxy w Visual Studio, który w przypadku każdego przyzwoitego projektu szybko się starzeje.
Jeśli wybierasz tę trasę, możesz również pozbyć się punktu końcowego MetaDataExchange, ponieważ jest on potrzebny tylko do opisania usługi klientowi. Ponieważ wszystko robisz w złożonym zestawie, nie potrzebujesz opisu usługi, ponieważ masz już Opis usługi w postaci kodu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-11 12:17:48
Zwykła struktura, której używam to:
Common-zawiera interfejsy, dane-umowy, umowy o świadczenie usług, klasy abstrakcyjne itp; Client-reference Common, zawiera klasę serwera proxy; Server-references Common, zawiera rzeczywiste klasy implementacji;
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-11 12:18:29