Thinking about the structure and the layering of the components of solutions is important for software architects. It’s about getting the right distance to a concrete implementation, detecting the principles and unnecessary deviations.
Sometimes those thoughts exceed this range and lead into almost religious discussions about holy principles.
Discussing the Model-View Controller (MVC) is one of those topics that describes the distribution of objects and functionalities of a application with a user interface on a high level. There are books about I and a also the material on the web is very detailed.
Because AJAX style applications is for many developers a new kind of modeling web applications I have collected some of my thought on this topic.
Here I want to look and analyze the existing AJAX Engine and not build a ideal optimal AJAX architecture.
Definition of MVC
There are many different definitions for the Model-View-Controller Pattern (google it). I stay with the short one that can actually be found at Wikipedia: http://en.wikipedia.org/wiki/Model-view-controller
- Model: This is the domain-specific representation of the information (data and methods) on which the application operates.
- View: This renders the model into a form suitable for interaction, typically a user interface element.
- Controller: This responds to events, typically user actions, and invokes changes on the model or view as appropriate.
The Model part of the architecture all is relatively easy to discover in the WebServices. Here all functional aspects should be discoverable. There are of course also functional aspects in the User Interface but this code is implementing a more comfortable way of interaction and handles topics of the presentation.
Based of the role this code takes over in the whole architecture some typical aspects very similar to the SOA architecture of the model can be identified. Here some keywords:
- Independent of HTML objects
- No culture or language specific implementations
- Manipulating and storing data
- Checking and securing of the parameters of the webmethods.
- Reliable algorithms and functionalities
- UI Events
- Active elements like input fields
- Layout elements and decorative additions
- Converting of numbers and date formats to strings
- Methods to support the working
But where is the Controller part in a AJAX application and how does it work ?
A simple answer is obvious: The AJAX Engine. Beside the WebService and the HTML there are only the script include files left to implement this part. The proxy methods for the webservices can be defined as part of the network infrastructure.
When comparing the traditional ASP.NET Web Forms with the MVC pattern the page-controller term is used very often. When comparing the 2 most used approaches ASP.NET and Struts you can easily detect that the server side implementation only covers the collaboration of the objects of a single page.
The transitions between the pages are not really supported with a structure by ASP.NET 1.1. Hyperlinks or Redirect statements are used on the server and some problems have to be solved for transferring information from one page to the next one. With ASP.NET 2.0 it is possible to have 2 pages in memory at once and transferring data is easier to implement but this is no solution for controlling the global flow of a web application.
Struts mixes up both aspects what may end in complex struts-config.xml files.
Both approaches for realizing web applications are described and compared regarding the MVC pattern in http://msdn.microsoft.com/library/en-us/dnaspp/html/ASPNet-ASPNet-J2EE-Struts.asp as well as in http://struts.apache.org/userGuide/building_controller.html.
I have to compare this situation with the 2-tier application architecture of the 90’s. Here the controller also was implemented on the (fat) client and the server added data and methods (SQL connections and stored procedures).