views:

48

answers:

2

Let's consider that I have an asp.net page which will go to the server after a client-side event and will do "some stuff" and show a return value of this process on the UI afterwords.

My question is, if I am working in the same domain, how should I decide between creating a web-service and calling that AND simply raising a post-back and handle this "some stuff" on the aspx page itself?

Under what conditions creating a web-service becomes meaningful to overcome some processes while working in the same domain?

A: 

I would look at how fast it takes for the post and reload action to occur. It depends on the user's expectations. Most people, if they know they are using a browser, will find that up to two seconds is just about acceptable for the action to occur, and the screen to be reloaded. On the other hand, in one of my jobs, I was using ASP.NET to drive a touchscreen, and this just looked totally wrong, so I refactored the code to use a static web page plus a WebService component.

You also need to take into account the capabilities of the browser. In the example above, I knew that I was only using IE6, so I could afford to write my Javascript code to take advantage of that browser. You may not be so lucky. If you are to use a web service which has client update, you should ensure that you target a version of Javascript and DOM that is supported by all your target browsers.

Mark Bertenshaw
+1  A: 

There are no hard-and-fast rules. However, I can offer a few high-level guidelines:

  1. Prefer an .aspx page if the result includes a significant amount of markup (HTML, JS, etc), or where generating the results is simplified by having access to control state from the original page. Keep in mind that the Page object carries a significant amount of overhead with it.
  2. Prefer a web service for queries that can be parameterized and that return structured data
  3. Prefer an HttpHandler for queries with simple parameters that return either simple, full-custom text or binary (such as an image)
RickNZ