Jquery WCF vs Pagemethods

Question

Jestem na wczesnym etapie rozwoju strony internetowej przy użyciu Jquery. Zastanawiam się, czy użyć usługi Pagemethods lub klasy usług WCF. Widziałem w jednej z odpowiedzi SO, która mówi, aby używać WCF we wszystkich przyszłych wymaganiach w jak największym stopniu. Bardzo wdzięczni, jeśli ktoś może wyjaśnić, jakie są decydujące czynniki i aspekty bezpieczeństwa.

Answer 1

PageMethods używają dużo tej samej technologii używanej przez usługi sieciowe ASMX. Ta technolgia jest w stagnacji. Nie oczekuje się, że zostanie ulepszony, a tylko krytyczne błędy powinny zostać naprawione. To nie jest dobra podstawa dla kawałka kodu gotowego do produkcji.

Answer 2

Nie ma nic złego w korzystaniu z metody strony lub usługi skryptowej ASMX, jeśli spełniają one wymagania.

WCF zdecydowanie przynosi dodatkową moc, elastyczność i funkcje do stołu, ale jest to karane dodatkową komplikacją. Jeśli nie zamierzasz korzystać z tych ulepszeń, to tylko tylko przynosi złożoność.

Ludzie powiedzą ci, że podejście ScriptService jest "starsze", oparte na tekście nagłówka w jednym artykule MSDN, ale jest to nieproporcjonalne. W rzeczywistości newer versions of those same articles nie jest już opatrzone zastrzeżeniem. Upuszczenie musiało być świadomą decyzją. ASP.NET AJAX i ScriptServices po stronie serwera nie pojawią się w najbliższej przyszłości.

Jeśli hostujesz punkt końcowy oddzwaniania AJAX w ramach tego samego projektu, co strona, która będzie go wywoływać, naprawdę nie możesz pokonać metod Page Methods i ScriptServices w celu ułatwienia użycia. Nigdy nie widziałem dobrego argumentu przemawiającego za tym, dlaczego kara złożoności WCF jest uzasadniona w tym scenariuszu, innym niż argumenty FUD dotyczące przestarzałości.

Usługa JavaScriptSerializer usługi ScriptService/Page umożliwia również deserializację DateTime i wyliczanie parametrów wejściowych nieco bardziej elastycznie niż DataContractJsonSerializer WCF, co jest często bardzo przydatne.

Answer 3

Niedawno w obliczu podobnej decyzji - oto kilka rzeczy, które silnie wpłynęły na naszą decyzję:

ASMX i PageMethods prowadzone w ramach usługi ASP.NET, dzięki czemu mogą one udostępniać te same dane sesji jako stron ASP.NET. Jeśli intensywnie korzystasz z sesji (nie będę się zajmować tym, czy jest to dobra praktyka, czy nie - to zupełnie inna dyskusja), wtedy możliwość dzielenia się nią między rozmowami na stronie i połączeniami z serwisem internetowym może być znaczącą korzyścią. W naszym przypadku faktycznie przechowujemy pewne informacje o autoryzacji w sesji - jeśli zdecydujemy się na wdrożenie naszych usług internetowych jako WCF, musielibyśmy również wdrożyć własną strukturę pojedynczego logowania między usługą internetową a usługą ASP.NET. Nic w tym złego, ale czas na projektowanie/programowanie/testowanie może nie być warty zainwestowania.

Jeśli Twój serwis internetowy jest hostowany na innym adresie/porcie niż twoja usługa ASP.NET, wszystkie wywołania do niego ze strony będą uznawane za skrypty krzyżowe (XSS) i będą znacznie ograniczone przez przeglądarkę. Istnieją rozwiązania tego problemu (głównie w formie JSONP), ale te obejścia również mają ograniczenia; na przykład obsługiwane są tylko żądania HTTP typu GET. Ponieważ metody ASMX/PageMethods są wykonywane na samym serwerze ASP.NET, nie będą traktowane jako żądania XSS. Oczywiście, jeśli możesz zagwarantować, że twoja usługa WCF będzie zawsze wdrażana na tym samym adresie/porcie co serwer ASP.NET, nie będą one również uważane za XSS - w takim przypadku ten problem jest dyskusyjny.

Z przyszłościowego punktu widzenia prawdopodobnie WCF będzie zwracać większą uwagę (poprawki, ulepszenia itp.) Od MS niż ASMX/PageMethods. Jednak technologia NO jest całkowicie odporna na przyszłość (nie sądzicie, że za 10 lat będziemy nadal pisać usługi WCF, czyż nie?).Więc naprawdę musisz zmierzyć swój własny poziom kompresji (lub klientów) w odniesieniu do możliwej przyszłej amortyzacji ASMX.