Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
I would recommend extra and better utilities, like full clientside frameworks (EXT, YUI, Dojo), ASP.NET MVC and client-side code managment like Curl.js and Backbone.js –  Raynos Jul 22 '11 at 15:11
3  
This is not enough information to really asses the situation. If the tiers are separated cleanly, why should it become unwieldier with jQuery than with any other frontend? What do you mean by data-element? Structures or rows? –  Falcon Jul 22 '11 at 15:11
    
@kittyhawk, do you mean that a single AJAX call would be sending many parameters to a server side method, or how you should handle the fact that you may have hundreds of separate AJAX functions? –  The Muffin Man Aug 6 '11 at 8:53

2 Answers 2

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.