Demystifying The Code

AJAX Q & A Question 6: Question regarding Page Methods

Question:  In your presentation, you recommended not having web methods inside of ASPX pages in favor of having a centralized asmx web service. Doesn’t that mean every page would have a larger ovehead by having the client code to generate proxies for all methods?

Answer:

Before I begin answering the question, let me set some context around the discussion.  In a code camp presentation, I was discussing accessing services using the AJAX client libraries.  I discussed calling services exposed in *.asmx pages, as well as WCF services using the new webHttpBinding.  A question arose regarding calling static page methods via client script, or at least that is how I interpreted the question.  Before I move on, I’ll provide an example of how to call page methods. 

Here is the code to create the static PageMethod in the code behind:

PageMethod

Here is the same page method defined inline:

PageMethodInline

Here is the client code that calls the method:

CallPageMethod

Back to the answer…  There are really 2 questions to answer here: 1) Why did I suggest that you should not use page methods and 2) the question regarding whether or not there is more page overhead with the use of asmx services because of the proxy generation:  With regards to the first question, it is really a matter of opinion.  When designing service tiers, I buy into the separation of the actual service and how the service is exposed.  Essentially, if you look at one of the major design goals of WCF was to separate the service development from the decision of how the service is exposed.  This allows one to expose the service over multiple transports (http, wse, tcp, etc).  In support of this in AJAX is the new webHttpBinding, which allows you to access WCF services easily from ASP.NET AJAX.  The binding supports the generation of a client proxy class that greatly simplifies the ability to call these services.

I tend to develop my services in a manner that supports this methodology.  Secondly, PageMethods are only accessible by the page containing them.  They are not reusable across multiple pages.  Lastly, I believe it makes for a more maintainable application if the services are separated from the page / UI logic.  The code in my pages is always UI centric, while I have my business logic and service tiers separated.

In answering the second question: Doesn’t that mean every page would have a larger ovehead by having the client code to generate proxies for all methods?  The answer is, probably not (and it depends upon how you architect it).  First of all, there is proxy code that is generated for PageMethods.  Take a look at the ‘View Source’ for the previous PageMethod:

InlineCode

So, in the case where the asmx has the same number of methods as pagemethods, it should be roughly equal.  The next issue may be that there are a large number of methods in the asmx page and only a percentage are being used on a single page.  If this is an issue, a simple solution is copy the proxy code into a *.js file and add a script reference to it.  This file will then be cached by the browser and you will find that this is quite a bit more performant than the PageMethods on a per page basis (on the second page and thereafter).  This is quite simple to do.  Assume your asmx page is named Test.asmx and the url is http://www.robbagby.com/Test.asmx you could type http://www.robbagby.com/Test.asmx/js in the browser, click save and save the proxy code to a location accessible by your project.  Then add a ScriptReference to this code in the ScriptManager and remove the ServiceReference to the asmx.  (BTW, the same holds true for .svc WCF Service files).

Have a question?  Email rob.bagby@microsoft.com and I’ll add it to the list.

 

Regards

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

Demystifying The Code