Wyniki usługi sieci Web programu ASP.NET, klasy proxy i konwersja typów

Question

Wciąż jestem nowy w świecie ASP.NET, więc mogłem być daleko od bazy, ale jak dotąd jest to najlepsze z mojej (ograniczonej) wiedzy !

Powiedzmy, że mam standardowy obiekt biznesowy "Kontakt" w przestrzeni nazw Business. Piszę usługę sieciową, aby pobrać dane kontaktu z bazy danych i zwrócić je. Następnie piszę aplikację kliencką, aby poprosić o te informacje.

Teraz też tworzę metodę użyteczności, która bierze "kontakt" i robi z nią trochę magii, jak mówi Utils.BuyContactNewHat(). Co oczywiście ma kontakt typu Business.Contact.

Następnie wracam do aplikacji klienckiej i chcę korzystać z metody BuyContactNewHat, więc dodaję odniesienie do mojej nazwy Utils i tam jest. Jednak pojawia się problem z:

Contact c = MyWebService.GetContact("Rob); 
Utils.BuyContactNewHat(c); // << Error Here 

Ponieważ typ powrót GetContact jest MyWebService.Contact i nie Business.Contact jak oczekiwano. Rozumiem, dlaczego tak jest, ponieważ podczas uzyskiwania dostępu do usługi sieciowej, faktycznie programujesz przeciwko klasie pośredniej generowanej przez WSDL.

Czy istnieje "łatwiejszy" sposób radzenia sobie z niedopasowaniem tego typu? Rozważałem być może próbę stworzenia ogólnej klasy konwertera, która używa odbicia, aby zapewnić, że dwa obiekty mają tę samą strukturę, niż po prostu przenoszenie wartości między nimi.

Answer 1

Jesteś na dobrej drodze. Aby przenieść dane z obiektu proxy z powrotem do jednego z twoich obiektów, musisz wykonać kod lewostronny. tj. kopiować wartości właściwości. Założę się, że istnieje już ogólna metoda, która używa refleksji.

Niektórzy ludzie używają czegoś innego niż usługa internetowa (.net remoting), jeśli chcą po prostu uzyskać obiekt biznesowy przez sieć. Lub użyją serializacji binarnej. Zgaduję, że korzystasz z usługi internetowej z jakiegoś powodu, więc będziesz musiał wykonać kopiowanie nieruchomości.

Answer 2

Nie musisz używać generowanej klasy, którą daje ci WSDL. Jeśli spojrzysz na kod, który generuje, jest to po prostu wykonywanie wywołań w niektórych klasach architektury .NET w celu przesyłania żądań SOAP. W przeszłości skopiowałem ten kod do normalnego pliku .cs i edytowałem go. Chociaż nie próbowałem tego specjalnie, nie widzę powodu, dla którego nie można pominąć definicji klasy proxy i używać oryginalnej klasy do otrzymywania wyników wywołania SOAP. Musi już robić refleksje pod maską, wydaje się wstydem zrobić to dwa razy.

Answer 3

Polecam, aby spojrzeć na pisanie rozszerzenia importu schematu, którego można użyć do sterowania generowaniem kodu proxy. To podejście może być użyte do (z gracją) rozwiązania problemu bez użycia kostek (takich jak kopiowanie obiektów z jednej przestrzeni nazw do drugiej lub modyfikowanie klasy reference reference.cs generowanej przez serwer proxy w celu zastąpienia go następnym razem po zaktualizowaniu odwołania do WWW).

Oto (bardzo) dobry tutorial na temat:

http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wsproxy.mspx