N-Tiered Web App Using JQuery/ASP.NET Web Services

Question

For fairly small, non-complex web applications, we have utilized jQuery to make asynchronous calls to an ASP.NET web service for interaction with our Sqlite data store. This has proven to be a pretty clean way to isolate the application tiers while taking advantage of the powerful client-side functionality of JQuery.

However, we are currently in the process of designing a larger application that consists of potentially hundreds of data elements. I am concerned that the sort of architecture mentioned above could get unwieldy pretty fast if we are passing hundreds of elements into the web service from a jQuery ajax post.

I was interested in others experience with this sort of design and whether you would recommmend another approach.

Answer 1

Based on the information you provided, I think people can only advice, not provide an architecture:

1. Try to wrap jQuery functionality, specifically ajax part, because you may want to create a centralized place to do something later in your project (for example, to implement client-side redirection to login page on ajax calls, which is commonly known as session management with ajax)
2. Avoid Page Methods and stick with web services. The main purpose of Page Methods is that, they are miniature web services, scoped to the page. But in large applications, sooner or later, you need that method in another page too. Thus, try to use web services as much as you can.
3. One of the biggest problems of large web applications is that, they get bloated with tens of client-side libraries. You need and HTML editor, you add many libraries. You need JavaScript lazy loading, you add libraries. You need unit testing in JavaScript, you add libraries, and so on and so forth. In small projects, people accept to include every library in a master page, even if it's not used in one derived page. However, in large applications, you may come across a point in which, you have 20 js libraries on one page, from which you only use jQuery. You need to address this problem on a regular basis.
4. Another problem I personally have experienced is paths (URLs) to your web services in JavaScript. They can become a headache when you simply reorganize the file system structure of your project as it gets bigger and bigger. I recommend either change to MVC (so to get the URL of actions via Url.Action method), or to just create some kind of PathBuilder utility class to generate the URL of a web service based on some parameters.

Server architecture seems to not being touched that much with larger projects.

Answer 2

I highly recommend switching to YUI and taking advantage of it's powerful event handling. You can build each element of the page as a unique widget and each can subscribe to events that you create and fire (example: _on_validate_request, _on_validate_request_response, _on_before_submit).

YUI is much more verbose than jQuery, but the events are worth it for complicated/advanced web UI.