Ajax for Asp.Net Best Practices

Topics: Web Client Software Factory
Mar 6, 2007 at 8:11 PM
I am looking for some advice on what people think is a good way to use Ajax with the WCSF. I know there is a issue tracker ticket for this, but I was hoping to generate more conservation and get so opinions back. Now it is pretty easy to get it working. You just have to add the right settings to your web.config. Now for the tricky part. I think there are 3 big unanswered questions.

1. Page Translations - This probably has to wait for the next update. So I must say I like how each view has it's own aspx page. This makes things a lot easier, especially to break up work between developers. Now what I think it would be really nice if you could select a "Ajax Page Load" setting. So basically in content section would get a loading image and look really cool. But this is not quite all the way there which leads to question 2.

2. Internal page translations - Also needs to wait for an update. So here I go. So in the control extenders there is a Popup. So I should be able to show that popup when event X happens. Right now I tend to just go to the next page. What would be super sweet (Think Cartman) would be if we have a popup control to throw up on the page flow, like the page we have now. Anyway I need to think more about this one, so if anyone else has ideas please say something. I mean right now is our best chance to influence the p&p people to get what we want :)

3. Ajax Service Calls - So this one is something I would like some help with. Where is the correct place in your code to put calls to the server to make yo ajax controls do stuff. Take the autocomplete control. It wants a web service or a page method call to populate itself. Right now all my aspx.cs files are doing is calls like

this._presenter.DoSomthing();

The presenter does all the work. So should I keep this up in someway, so the ajax control goes through the presenter or should the page call the service directly? I am trying to find the best separation here. What are other people doing? Is the view supposed to encapsulate all the logic or should the aspx.cs file have some?

Mar 8, 2007 at 3:39 PM
You bring up an excellent set of questions, because I know the top issue right now is AJAX Support in WCSF. However, I don't know what that means. There are a lot of votes but not many have commented on specific functionality.

Do voters just want the default web.config to be set-up for AJAX or are they expecting a new factory / framework that completely eliminates postbacks, etc? I assume the latter and the WCSF Team will probably have to generate a completely new Guidance Package just like they did for Web Application Projects.

Maybe the WCSF Team can talk more about what it means to them to include AJAX Support in the next release of WCSF because I don't know how much specific input they have gotten on the subject. It may be that your questions around #1 and #2 may be in their plans.

As far as your question #3. It sounds like you are doing it right. IMHO...

The view ( ASPX Page and Code Behind ) do nothing more than pass event calls to the presenter and respond to presenter requests.

The presenter actually is not doing any work. It just facilitates communication between the controller and the view. No business / domain logic code here. Nothing other than moving request back and forth between the view and the controller.

The controller can be thought of as doing all the work, but really it should only be delegating work to domain objects and services. At the most, your controller could be a very thin transactionscript layer that provides work flow and transactional ( unit of work ) services and the domain objects and services it consumes ( via dependency injection ) do all the work.

If you are calling web services, the web method would either call the Controller Class or perhaps a service / domain object directly depending on the nature of the call. It gets a little fuzzy depending on how you build your application, but the key is that your web service and web pages will want to use the same business logic. You don't want to duplicate the logic in different locations depending on what UI calls it. Therefore, you don't want that business logic too close to the UI. You don't want it at the ASPX, ASPX Code Behind, or Presenter Class levels. You want it pass them and more into the controller, domain object, and service classes so it can be used by multiple clients without duplicating logic.

IMHO, that is really the goal of the MVP pattern and why the WCSF included it - mainly to keep your business / domain logic out of your view / UI so you can better re-use the same logic throughout the application. It also allows you to test the presenter class and essentially your UI, but some developers have not built up the skills yet to test so that is really a secondary benefit.

Hopefully this helps,

Dave

_______________________

David Hayden
Microsoft MVP C#