Section 12.14. Comparing Our AJAX-Driven Application against a Standard MVC Model

12.14. Comparing Our AJAX-Driven Application against a Standard MVC Model

You have many different design choices that you can make when building a Web application, but one that is often used is the MVC model. In an MVC application, your model code handles interacting with the database, the view manages how the content is displayed, and the controller ties things together. When you move to an AJAX-driven application, this model will still exist, only now you have the possibility of having it twice: once on the server and once on the client. In many cases, the controller and view classes will mainly disappear from the server side because that functionality is transparently provided by the AJAX communications library.

In the ticket manger, the controller functionality was provided by the HTML_AJAX_Server class. The server class takes incoming requests and maps them to the appropriate method on the ticket class; it then takes the output and uses a JSON serialization class as the view. In the ticket manager, the model is less clear, but the model component is still the ticket class. In some ways, the ticket class is still a controller because it handles user input, decides what to do with it, and then returns data or errors. As the ticket manager application grows, a common refactoring approach would be to pull the code that creates the queries into its own classes, leaving only the code for cleaning the input and for picking the entity to work with in the ticket class. You can also build an AJAX-driven application without the use of JSON; instead of returning data to the client, you would return chunks of HTML. In an HTML, chunk-style AJAX application, you would keep the standard view component in the MVC model. (The view component is a template in most Web applications.)

On the JavaScript side of the application, you can also choose an MVC model to drive your application. However, you're less likely to see a pure implementation because most JavaScript code is event driven. (That is, it responds only to user interaction, such as the clicking of a link.) In addition, it is harder to work in a controller model than the standard, URL-driven approach used on the server. A strict view also isn't needed on the JavaScript side because you can interact directly with the DOM, but you may find template-based approaches to be quite useful because the templates make the development processes much simpler. Models follow much of the same pattern; in a simple AJAX application, they can be simple data structures mapped directly from the server using JSON. However, as features are added, you'll find it useful to wrap this data inside JavaScript classes. These classes can take care of caching data in the client, handle validation, and even combine multiple requests to allow you to lower the number of requests you send to the server.

Overall, building an AJAX-driven application has the tendency to lower the amount of code you have on the server and increase what you have on the client. However, even with large amounts of functionality being provided by an AJAX library, the server-side code will still need to provide more than simple data access. All of the application's security will have to be enforced on the server. You'll also need to manage the first-time page generation on the server, which may include preloading large amounts of data to save you from doing a bunch of AJAX requests as soon as the page is loaded. The server will also tend to have methods that combine multiple-step processes; due to the high latency of AJAX requests, you will want to minimize the number of round trips to the server that are required to process a single action.

Building a fully AJAX-driven application gives you a lot of power, but be careful when using this approach. You'll have a lot more important logic running on the client, so you'll need to update your testing approaches to account for this. You also want to be careful about ending up with a design that leaves you with a complex back end and then a complex front end that performs many of the same functions. If you have a fully driven AJAX application, you should strive to keep one side of the application as simple as possible. If you're pushing data out using JSON, that side should be the back end; if you're pushing out chunks of HTML, that side is the front end. If you let both sides become complicated, you'll find yourself with two interdependent pieces that are hard to maintain and debug.