WCF ChannelFactory a generowanie serwera proxy

Zastanawiasz się tylko, w jakich okolicznościach wolisz generować serwer proxy z usługi WCF, gdy możesz po prostu wywoływać wywołania przy użyciu ChannelFactory?

W ten sposób nie będziesz musiał generować serwera proxy i martwić się o jego regenerację po zaktualizowaniu serwera?

Dzięki

Istnieją 3 podstawowe sposoby tworzenia klienta WCF:

1. Pozwól programowi Visual Studio wygenerować serwer proxy. To automatycznie generuje kod, który łączy się z usługą, odczytując WSDL. Jeśli usługa ulegnie zmianie z jakiegokolwiek powodu, musisz ją zregenerować. Dużą zaletą tego jest to, że jest łatwy w konfiguracji - VS ma kreatora i wszystko działa automatycznie. Wadą jest to, że polegasz na VS, aby wykonać całą ciężką pracę za Ciebie, przez co tracisz kontrolę.

2. Używaj ChannelFactoryze znanym interfejsem. Zależy to od posiadania lokalnych interfejsów opisujących usługę (kontrakt serwisowy). Dużą zaletą jest to, że można łatwiej zarządzać zmianami - nadal musisz rekompilować i naprawiać zmiany, ale teraz nie regenerujesz kodu, tylko odwołujesz się do nowych interfejsów. Często jest to używane, gdy kontrolujesz zarówno serwer, jak i klienta, ponieważ oba mogą być znacznie łatwiejsze do podrobienia na potrzeby testów jednostkowych. Jednak interfejsy można napisać dla dowolnej usługi, nawet REST - spójrz na to Twitter API .

3. Napisz własne proxy - jest to dość łatwe, szczególnie w przypadku usług REST, przy użyciu HttpClientlub WebClient. Zapewnia to najdokładniejszą kontrolę ziarna, ale kosztem wielu interfejsów API usług znajdujących się w łańcuchach. Na przykład: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content;- jeśli szczegóły API ulegną zmianie, nie napotkasz błędu do czasu uruchomienia.

Osobiście nigdy nie lubiłem opcji 1 - poleganie na automatycznie generowanym kodzie jest bałaganiarskie i traci zbyt dużą kontrolę. Poza tym często stwarza problemy z serializacją - w rezultacie otrzymuję dwie identyczne klasy (jedną w kodzie serwera, jedną generowaną automatycznie), które można uporządkować, ale jest to uciążliwe.

Opcja 2 powinna być idealna, ale kanały są trochę zbyt ograniczające - na przykład całkowicie tracą zawartość błędów HTTP . To powiedziawszy, posiadanie interfejsów opisujących usługę jest znacznie łatwiejsze do kodowania i utrzymania.

Używam ChannelFactory wraz z metodą MetadataResolver.Resolve. Konfiguracja klienta jest kłopotliwa, więc pobieram ServiceEndpoint z serwera.

W przypadku korzystania z ChannelFactory (Of T) T jest oryginalną umową, którą można uzyskać z odwołania w projekcie lub wygenerowaną instancją kontraktu. W niektórych projektach wygenerowałem kod z odwołania do usługi, ponieważ nie mogłem dodać odwołania do biblioteki DLL kontraktu. Możesz nawet wygenerować kontrakt asynchroniczny z odwołaniem do usługi i użyć tego interfejsu kontraktu z ChannelFactory.

Głównym celem korzystania z ChannelFactory było pozbycie się informacji o konfiguracji klienta WCF. W poniższym przykładowym kodzie można zobaczyć, jak osiągnąć klienta WCF bez konfiguracji.

Dim fixedAddress = "net.tcp://server/service.svc/mex"
Dim availableBindings = MetadataResolver.Resolve(GetType(ContractAssembly.IContractName), New EndpointAddress(fixedAddress))
factoryService = New ChannelFactory(Of ContractAssembly.IContractName)(availableBindings(0))
accesService = factoryService.CreateChannel()

W moim ostatnim projekcie, availableBindings są sprawdzane pod kątem używania net.tcp lub net.pipe, jeśli są dostępne. W ten sposób mogę użyć najlepszego dostępnego wiązania dla moich potrzeb. Opieram się tylko na fakcie, że punkt końcowy metadanych istnieje na serwerze.

mam nadzieję, że to pomoże

Przy okazji, odbywa się to za pomocą platformy .NET 3.5. Jednak działa również z 4.0.

Cóż, aby z niego skorzystać ChannelFactory<T>, musisz chcieć udostępniać zestawy kontraktowe między usługą a klientem. Jeśli nie masz nic przeciwko, ChannelFactory<T>możesz zaoszczędzić trochę czasu.

Proxy zbuduje funkcje asynchroniczne, co jest miłe.

Moja odpowiedź jest swego rodzaju podsumowaniem odpowiedzi Keitha i Andrew Hare'a .

Jeśli nie kontrolujesz serwera, ale masz tylko WSDL / URL, wygeneruj proxy za pomocą Visual Studio lub svcutil. (Zauważ, że Visual Studio czasami zawodziło, kiedy svcutil działa lepiej).

Kiedy kontrolujesz zarówno serwer, jak i klienta, udostępniaj interfejsy / kontrakty i wywołuj ChannelFactory
.

Nie chodzi tylko o oszczędność czasu. Korzystanie z serwera proxy wygenerowanego przez WSDL jest niebezpieczne, ponieważ jeśli zapomnisz zaktualizować odwołanie do usługi, możesz pozostawić rozwiązanie w niespójnym stanie. Wszystko się kompiluje, ale umowa serwisowa jest zepsuta. Zdecydowanie sugeruję korzystanie z ChannelFactory, gdy tylko jest to możliwe, aby ułatwić sobie życie.

Możliwą alternatywą może być napisanie skryptu prebuild, który wywołuje narzędzie SVCUtil w celu utworzenia proxy za każdym razem, gdy budujesz swój projekt, ale w każdym razie ChannelFactory jest znacznie bardziej schludny i elegancki.