Jquery WCF vs Pagemethods

I am at the early stages of developing a web site using Jquery. I am wondering whether to use Pagemethods or WCF service class. I saw in one of the SO answers which says to use WCF in all future requirements as much as possible. Highly appreciate if anyone can explain what are the de开发者_如何学Pythonciding factors and security concers.

---

There's nothing wrong with using a Page Method or ASMX ScriptService if they meet your requirements.

WCF definitely does bring additional power, flexibility, and features to the table, but that comes at a penalty of additional complexity. If you don't intend to use those improvements then it only brings the complexity.

People will tell you that the ScriptService approach is "legacy", based on a bit of header text on one MSDN article, but that's blown out of proportion. In fact, newer versions of those same articles no longer carry the disclaimer. Dropping it had to have been a conscious decision. Server-side ASP.NET AJAX and ScriptServices aren't going anywhere in the foreseeable future.

If you're just hosting an AJAX callback endpoint within the same project as the page that will be calling it, you really can't beat Page Methods and ScriptServices for ease of use. I've never seen a good argument speaking to why WCF's complexity penalty is justified in that scenario, other than FUD arguments about obsolescence.

The ScriptService/Page Method's JavaScriptSerializer also deserializes DateTime and enum input parameters slightly more flexibly than WCF's DataContractJsonSerializer, which is often quite handy.

---

I recently faced a similar decision - here's some things that strongly influenced our decision:

ASMX and PageMethods run within the ASP.NET service, so they can share the same session data as the ASP.NET pages. If you make heavy use of the session (I won't address whether that's a good practice or not - that's a different discussion entirely), then being able to share it between your page calls and webservice calls can be a significant benefit. In our case, we actually store certain authorization info in the session - if we chose to implement our webservices as WCF, we would also need to roll our own single-sign-on framework between the webservice and ASP.NET service. Nothing wrong with that, but it's design/dev/testing time you may not want to invest.

If your Webservice is hosted on a different address/port than your ASP.NET service, then all calls to it from your page will be considered cross-site scripting (XSS) and will be significantly limited by the browser. There's workarounds to this (mostly in the form of JSONP), but those workarounds have limitations as well; for example, only GET-type http requests are supported. Since ASMX/PageMethods are executed within the ASP.NET server itself, they won't be considered XSS requests. Of course, if you can guarantee that your WCF service will always be deployed on the same address/port as your ASP.NET server, they won't be considered XSS either - in that case, this issue is moot.

From a future-proofing standpoint, it's likely that WCF will see more attention (patches, enhancements, etc.) from MS than will ASMX/PageMethods. However, NO technology is completely future-proof (you don't think we'll still be writing WCF services 10 years from now, do you? ;). So you really have to measure your own compfort level (or your clients') with regard to ASMX's possible future deprecation.

---

PageMethods use much of the same technology used by ASMX web services. That technolgy is stagnant. It is not expected to be enhanced, and only critical bugs are expected to be fixed. That's not a good basis for a Production-ready piece of code.