The Evolution of MVC Architecture and the Web
How was MVC Architecture applied in the past?
In the past, all three parts of MVC Architecture, the model, view, and controller, resided on the web server (see the figure below).
Old MVC Architecture Implementation:
When a request was made to the web server, the controller determined what page the user should be directed to, what data to pull from the data server, how to build the model, and how to build the view. As soon as the view was created, HTML would then be generated and sent back to the client machine as a reaction. This was the fatal flaw of web applications in the past. Unlike desktop applications, if users needed to interact with the interface, the application must reload the whole page, because all of the parts of the MVC architecture were stuck on the web server.
This is the reason AJAX was born in 1995. Ajax allowed users to somewhat interact with a web application’s interface significantly better than before because individual requests could be made to the web server, which might then, in turn, respond with new data to update parts of the web page without reloading the whole page. AJAX still wasn’t an excellent solution, however, because every user interaction still needed to make separate requests to the web server.
How is MVC Architecture applied today?
Once the web world began to include AJAX, a new movement began to unfold called RIAs. With this model, the user may have a rich app experience without making requests to the web server with each action because the view part of the MVC architecture resides in the client (see the figure below)
New MVC Architecture Implementation:
This is a big deal because it means that we’re rethinking how MVC architecture is applied for web applications.
Here is an example. Let’s say that you’re using a web application that displays data. You enter some inputs, press “Enter”, and the web application sends a request to the web server. The controller then gets the appropriate data from the data server, creates a model of that data, and sends it back to the client via JSON. The client receives the JSON and replicates the model as native objects. If the user wants to see this data as a pie chart, the native model can be utilized to make a pie chart (which is a view) without making a request to the server. Likewise, if the user wants to see the data as a bar graph, the native model can be utilized to make a bar graph, again without making a request to the server. All of this is done without reloading the page, and only one request was made to the web server.
This post was written by Versitek