Jquery WCF vs. Pagemethods

Question

Ich bin in den frühen Phasen der Entwicklung einer Website mit Jquery. Ich frage mich, ob ich Pagemethods oder WCF Service Class verwenden soll. Ich habe in einer der SO-Antworten gesehen, dass WCF in allen zukünftigen Anforderungen so weit wie möglich verwendet werden soll. Ich wäre sehr dankbar, wenn mir jemand erklären könnte, was die entscheidenden Faktoren und Sicherheitsbedenken sind.

Answer 1

Es spricht nichts dagegen, eine Seitenmethode oder einen ASMX ScriptService zu verwenden, wenn sie Ihren Anforderungen entsprechen.

WCF bringt definitiv zusätzliche Leistung, Flexibilität und Funktionen mit sich, was jedoch mit zusätzlicher Komplexität erkauft wird. Wenn Sie nicht beabsichtigen, diese Verbesserungen zu nutzen, ist es nur bringt die Komplexität.

Man wird Ihnen sagen, dass der ScriptService-Ansatz "veraltet" ist, basierend auf einem Stück Überschrifttext in einem MSDN-Artikel, aber das ist übertrieben. In der Tat, neuere Versionen der gleichen Artikel nicht mehr mit dem Haftungsausschluss versehen. Der Verzicht darauf muss eine bewusste Entscheidung gewesen sein. Serverseitige ASP.NET AJAX und ScriptServices werden in absehbarer Zeit nicht verschwinden.

Wenn Sie nur einen AJAX-Callback-Endpunkt innerhalb desselben Projekts wie die Seite, die ihn aufruft, hosten, sind Page Methods und ScriptServices in puncto Benutzerfreundlichkeit nicht zu schlagen. Ich habe noch nie ein gutes Argument dafür gesehen, warum der Komplexitätsnachteil von WCF in diesem Szenario gerechtfertigt ist, abgesehen von FUD-Argumenten über Veralterung.

Der JavaScriptSerializer der ScriptService/Page-Methode deserialisiert auch DateTime- und Enum-Eingabeparameter etwas flexibler als der DataContractJsonSerializer der WCF, was oft recht praktisch ist.

Answer 2

Ich stand vor kurzem vor einer ähnlichen Entscheidung - hier sind einige Dinge, die unsere Entscheidung stark beeinflusst haben:

ASMX und PageMethods werden innerhalb des ASP.NET-Dienstes ausgeführt, so dass sie die gleichen Sitzungsdaten wie die ASP.NET-Seiten nutzen können. Wenn Sie die Sitzung intensiv nutzen (ich werde nicht darauf eingehen, ob das eine gute Praxis ist oder nicht - das ist eine ganz andere Diskussion), dann kann die Möglichkeit, sie zwischen Ihren Seitenaufrufen und Webservice-Aufrufen gemeinsam zu nutzen, ein großer Vorteil sein. In unserem Fall speichern wir bestimmte Autorisierungsinformationen in der Sitzung - wenn wir unsere Webservices als WCF implementieren würden, müssten wir auch unser eigenes Single-Sign-On-Framework zwischen dem Webservice und dem ASP.NET-Service einrichten. Daran ist nichts auszusetzen, aber es ist Design-/Entwicklungs-/Testzeit, die Sie vielleicht nicht investieren wollen.

Wenn Ihr Webservice unter einer anderen Adresse/einem anderen Port als Ihr ASP.NET-Dienst gehostet wird, gelten alle Aufrufe von Ihrer Seite als Cross-Site-Scripting (XSS) und werden vom Browser erheblich eingeschränkt. Es gibt zwar Umgehungsmöglichkeiten (meist in Form von JSONP), aber auch diese haben ihre Grenzen; zum Beispiel werden nur http-Anfragen vom Typ GET unterstützt. Da ASMX/PageMethods innerhalb des ASP.NET-Servers selbst ausgeführt werden, werden sie nicht als XSS-Anfragen betrachtet. Wenn Sie natürlich garantieren können, dass Ihr WCF-Dienst immer unter derselben Adresse/demselben Port wie Ihr ASP.NET-Server bereitgestellt wird, werden sie auch nicht als XSS-Anfragen betrachtet - in diesem Fall ist dieses Problem irrelevant.

Unter dem Gesichtspunkt der Zukunftssicherheit ist es wahrscheinlich, dass WCF mehr Aufmerksamkeit (Patches, Verbesserungen usw.) von MS erhalten wird als ASMX/PageMethods. Allerdings ist keine Technologie völlig zukunftssicher (Sie glauben doch nicht, dass wir in 10 Jahren noch WCF-Dienste schreiben werden, oder? ;). Sie müssen also Ihr eigenes Komfortniveau (oder das Ihrer Kunden) im Hinblick auf die mögliche zukünftige Veralterung von ASMX messen.

Answer 3

PageMethods verwenden weitgehend dieselbe Technologie wie die ASMX-Webdienste. Diese Technologie ist stagnierend. Es wird nicht erwartet, dass sie verbessert wird, und es wird erwartet, dass nur kritische Fehler behoben werden. Das ist keine gute Grundlage für ein produktionsreifes Stück Code.