In this post I will try to explain how the good old MVC paradigm applies to AJAX-based web applications.

I have always been fond of visualizing things because, imho, illustrations help better organize ideas and that in turn helps understand the concept better.

Let me introduce our artists first, the model, the view, and the controller.


Anyone who has been developing GUI applications for sometime have heard of the model-view-controller paradigm. Here we will try to describe how this paradigm works in a typical web application.

Let us define the model, view and controller in more detail:

view:
That's fairly easy. In a web application the view is what user sees and does not see but available to the client none the less. To extend it view consists of the rendered HTML, links, buttons (the visible part), hidden form fields (invisible parts to hold state data) and global javascript variances which as well hold the state data of the client

model:
Model can be defined as the DB back end. Which is, the database itself and any wrapper and helper classes that are used to communicate with the db. The database will be typically a DBMS like MySQL, Oracle, Sybase etc; but it is quite possible for the data to be stored in XML files or even in text files, it does not matter.

controller:
Well, controller is hard to define because no matter how much you try to separate, parts of it leak into model and view. Controller can be thougth as a class that can directly communicate to the model and the view. That is, the controller decouples model from the view. It changes the data persisting on the model and updates the view based on the fresh data.

Controller and model are implemented on the server side, whereas the view is the client side.
...

In a traditional (say desktop) application that applies MVC paradigm. The model implements an observer design pattern. That is, whenever the model changes; it notifies the view and the controller. In a Java desktop application this can be achieved with event handlers and even listeners. Whereas in a C# application this can be done via delegaes (which are somewhat different, in implementation, than Java event hanlders).

...

However, web applications are mostly disconnected (I will eloborate on the "mostly" part in a second), therefore it is not possible, or at least it is impractical, to implement an observer relation.

Will come to this later, but now let us observe how the controller interacts with the model and the view in a typical MVC Web application.



The controller updates the model and changes the view as well. After the model changes, it notifies the view and the controller.

The view and model is disconnected (client side and server side), and thus it is not possible for the model to notify the view. Therefore it is the controller's duty to update the view and hold model and the view in sync.

So in a web application, model indirectly notifies the controller sending status information (updated failed / operation succeeded etc.) gets the up to date data from the model and re-creates the view.

A typical scenario will be as follows:
The user will fill the data in the form, posting it to the server (say to the action servlet or the controller web application). Where the controller will update the db and then it will refresh the view by redirecting the server response to the view page where the user will retrive the updated data from the DB (the model).

This is how things work in a disconnected web application.

Now let us spill some AJAX around to glue the server and the client and generate a more connected environment.

Look ma! No Browser refresh!

In an AJAX application we will have additional layer between the view and the controller.



Those are the js/ajax delegates. To put it simpler, they are the js functions which trigger when the user interacts with the view, such as clicking a link, dragging a DHTML layer etc.

When user interacts with the view, the view notifies the controller through these delegates.

Please note that view is the client side, model and controller are the server side and the js/ajax part reside on the client acting as a glue between the view and the controller.

The view tells the controller to update the model (change the data) via js/ajax delegates.



Then the controller tells the model to update, and return a status report (success, failure and/or some other state data)



The model returns the state data.



And after that, the controller returns a response (as a responseText or responseXML) to the ajax stubs (through oncomplete or onerror event handlers)



And after receiving the state data in the responseText, the js/AJAX stubs update the view using this data (either using the data embedded in this response, or sending another AJAX request to the server to query the model and get fresh data).

That's it.

Have a lovely AJAX experience.

 bu yaziyi sevdin mi?  hemen una ekle!