WCF ChannelFactory vs generowanie proxy

Question

Zastanawiasz się tylko, w jakich okolicznościach wolisz generować proxy z usługi WCF, gdy możesz po prostu wywołać połączenia za pomocą ChannelFactory?

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

Dzięki

Answer 1

Istnieją 3 podstawowe sposoby tworzenia klienta WCF:

1. Niech Visual Studio generuje serwer proxy. To auto generuje kod, który łączy się z usługą, czytając plik WSDL. Jeśli usługa zmieni się z jakiegokolwiek powodu, musisz ją zregenerować. Dużą zaletą tego jest to, że jest łatwy w konfiguracji - VS ma kreatora i wszystko jest automatyczne. Wada polega na tym, że polegasz na VS, wykonując dla ciebie ciężką pracę, a więc tracisz kontrolę.

2. Użyj ChannelFactory ze znanym interfejsem. Jest to zależne od tego, czy masz lokalne interfejsy opisujące usługę (umowę o świadczenie usług). Dużą zaletą jest to, że można łatwiej zarządzać zmianą - nadal trzeba rekompilować i naprawiać zmiany, ale teraz nie regenerujesz kodu, odwołujesz się do nowych interfejsów. Zwykle jest to używane, gdy kontrolujesz zarówno serwer, jak i klienta, ponieważ oba mogą być o wiele łatwiej wyśmiewane podczas testowania jednostkowego. Jednak interfejsy mogą być napisane dla dowolnej usługi, nawet dla usług REST - spójrz na this Twitter API.

3. Napisz swój własny serwer proxy - jest to dość łatwe do wykonania, szczególnie w przypadku usług REST, przy użyciu HttpClient lub WebClient. Zapewnia to najdokładniejszą kontrolę ziarna, ale kosztem mnóstwa API usługowego będącego w ciągach. Na przykład: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - jeśli szczegóły zmiany interfejsu API nie wystąpią, błąd nie wystąpi do czasu wykonania.

Osobiście nigdy nie lubiłem opcji 1 - poleganie na generowanym automatycznie kodzie jest chaotyczne i traci nadmiar kontroli. Plus często powoduje problemy z serializacją - kończę na dwóch identycznych klasach (jedna w kodzie serwera, jedna generowana automatycznie), które można uporządkować, ale jest to ból.

Opcja 2 powinna być idealna, ale kanały są zbyt ograniczające - na przykład: completely lose the content of HTTP errors. To powiedziawszy, że interfejsy, które opisują tę usługę, są znacznie łatwiejsze do kodowania i utrzymywania.

Answer 2

No w celu wykorzystania ChannelFactory<T> musisz być skłonny do dzielenia się zespoły umowa między usługą a klientem. Jeśli jest to w porządku z tobą, to ChannelFactory<T> może zaoszczędzić ci trochę czasu.

Answer 3

Serwer proxy zbuduje funkcje asynchroniczne, co jest miłe.

Answer 4

Używam ChannelFactory razem z MetadataResolver.Resolve metoda. Konfiguracja klienta jest kłopotliwa, więc dostaję mój ServiceEndpoint z serwera.

Podczas korzystania z ChannelFactory (Of T), T jest oryginalną umową, którą można uzyskać z referencji w projekcie lub wygenerowanej instancji kontraktu. W niektórych projektach wygenerowałem kod z Service Reference, ponieważ nie mogłem dodać odwołania do biblioteki kontraktowej. Można nawet wygenerować umowę asynchroniczną z referencją do usługi i użyć tego interfejsu umowy z ChannelFactory.

Głównym celem używania ChannelFactory było pozbycie się informacji o konfiguracji klienta WCF.W przykładowym kodzie poniżej możesz 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 ostatecznym projekcie dostępneBindings są sprawdzane pod kątem użycia net.tcp lub net.pipe, jeśli są dostępne. W ten sposób mogę wykorzystać najlepsze dostępne oprawy do moich potrzeb. Opieram się tylko na tym, że na serwerze istnieje punkt końcowy metadanych.

Mam nadzieję, że to pomoże

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

Answer 5

Moja odpowiedź jest rodzajem podsumowania odpowiedzi Keith's i Andrew Hare's.

Jeśli nie kontrolujesz serwera, ale masz tylko WSDL/URL-generuj proxy używając Visual Studio lub svcutil. (Zauważ, że Visual Studio czasami zawodziło, gdy svcutil działa lepiej).

Gdy kontrolujesz zarówno serwer, jak i klienta, udostępnij interfejsy/umowy i zadzwoń do ChannelFactory
.

Answer 6

To nie tylko kwestia zaoszczędzonego czasu. Korzystanie z generatora proxy WSDL jest niebezpieczne, ponieważ jeśli zapomnisz zaktualizować referencję do usługi, możesz pozostawić rozwiązanie w niespójnym stanie. Wszystko się kompiluje, ale umowa o świadczenie usług jest zepsuta. Zdecydowanie sugeruję używać ChannelFactory, kiedy tylko jest to możliwe, ułatwisz sobie życie.

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