The Evolution of MVC

Take Model-View-Controller as an example. It's often referred to as a pattern, but I don't find it terribly useful to think of it as a pattern because it contains quite a few different ideas. Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. If this doesn't cause enough confusion you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers. – Martin Fowler, GUI Architectures (

People assume that the meaning of words is static. But that is simply not true. The meanings of words shift over time to adapt to a changing environment. In this blog entry, I discuss the evolution of the meaning of MVC: the Model View Controller pattern.

I discuss three stages in the history of MVC. I start at the beginning with the invention of the pattern in the context of the Smalltalk language. Next, I discuss the popularization of MVC in the JavaServer Pages and Ruby on Rails worlds. Finally, we reach the apex of the evolution of MVC: we discuss MVC in the context of ASP.NET.

MVC – The Smalltalk Years

The MVC pattern was invented by Trygve Reenskaug while he was a visiting scientist at the Smalltalk group at the famed Xerox Palo Alto Research Center. He wrote his first paper on MVC in 1978. He originally called it the Thing Model View Editor pattern, but he quickly changed the name of the pattern to the Model View Controller pattern. You can read his original papers here:

Reenskaug was trying to solve the problem of representing (modeling) complex real world systems such as “the design and construction of a major bridge, a power station or an off-shore oil production platform.” A human has a mental model of these systems and a computer has a digital model. How do you bridge the gap between the mental model and digital model?

He originally defined Models, Views, and Controllers like this:

MODELS - Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.

VIEWS -- A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter.

CONTROLLERS -- A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and passes these messages on to one or more of the views.

Realize that the MVC pattern was invented long before the first web browser. The MVC pattern was first implemented as part of the Smalltalk-80 class library. It was originally used as an architectural pattern for creating graphical user interfaces (GUIs). You can read about the early interpretation and history of the MVC pattern in the following articles:

GUI Architectures -

Model View Controller History --

The original meaning of the Model View Controller pattern was very different than the meaning associated with the pattern today. In the context of a Graphical User Interface, the Model View Controller pattern was interpreted like this:

MODEL – A particular piece of data represented by an application. For example, weather station temperature reading.

VIEW – One representation of data from the model. The same model might have multiple views associated with it. For example, a temperature reading might be represented by both a label and a bar chart. The views are associated with a particular model through the Observer relationship.

CONTROLLER – Collects user input and modifies the model. For example, the controller might collect mouse clicks and keystrokes and update the Model.

The original Model View Controller pattern can be represented with Figure 1.

Figure 1 – Original MVC Pattern


Notice, in this figure, that the View is updated indirectly from the Model. When the Model changes, the Model raises an event, and the View changes in response to the event.

Also, notice that the Controller does not interact directly with the View. Instead, the Controller modifies the Model, and since the View is observing the Model, the View gets updated.

According to Martin Fowler, the primary benefit of this original version of the MVC pattern is Separated Presentation (see which he defines like this:

Ensure that any code that manipulates presentation only manipulates presentation, pushing all domain and data source logic into clearly separated areas of the program

Separated Presentation is a special case of the Separation of Concerns (SoC) software design principle. As we’ll see, this is the common thread that unites all of the justifications of the MVC pattern. The MVC pattern provides you with a clear Separation of Concerns.

MVC – The JavaServer Pages Years

The meaning of MVC shifted radically with the introduction of JavaServer Pages (JSP). A draft specification of JSP included a section that described two methods of creating a JSP application: the Model 1 and the Model 2 method. You can read the draft specification here:

Even though this distinction was removed from the published version of the specification, the Model 1 and Model 2 terminology stuck.

In the Model 1 approach to creating a JSP application, browser requests are handled by a JavaServer Page directly. The JavaServer Page “accesses server components that generate dynamic content and displays the dynamic content in the browser.”

In the Model 2 approach, in contrast, the browser request is not handled by the JavaServer Page itself. Instead, the request is handled by a Java Servlet. The Servlet “generates a result and stores the result in [a] component. The servlet then calls a JavaServer Pages file, which accesses the component and displays the dynamic content in the browser.”

A Model 1 application does not use the Model View Controller pattern while a Model 2 application uses the Model View Controller pattern. When people discuss MVC in the context of a web application, they almost always mean the Model 2 version of MVC.

Realize that the Model 2 version of MVC is very different than the original version. In Model 2 MVC, the components of an MVC application work like this:

MODEL – Business logic plus one or more data sources such as a relational database.

VIEW – The user interface that displays information about the model to the user.

CONTROLLER – The flow-control mechanism means by which the user interacts with the application.

(Definitions taken from

In this new version of the MVC model, there is no longer any relationship between the View and the Model. All communication between View and Model happens through the controller. The Model 2 version of MVC can be represented with Figure 2.

Figure 2 – Model 2 MVC Pattern


IBM published these guidelines for deciding when to build a Model 1 versus a Model 2 application:

Table 2. Guidelines for using Model 1 or Model 2

Table 2. Guidelines for using Model 1 or Model 2


Model 1

Model 2

Type of Web application



Nature of developer's task

Quick prototyping

Creating an application to be modified and maintained

Who is doing the work

View and controller being done by the same team

View and controller being done by different teams


According to the guidelines, if you want to create an application that can be easily maintained for the long term, and your application is complex, then you should use Model 2. Otherwise, if you are creating a simple application that needs to be built quickly, then use Model 1.

Several web application frameworks have adopted the Model 2 MVC pattern. In the Java world, these frameworks include Struts, Tapestry, and Spring. In the Ruby world, these frameworks include Ruby on Rails and Merb. In the Python world, these frameworks include Django. And, of course, in the ASP.NET world, these frameworks include ASP.NET MVC.


Now we arrive at the present and we can discuss the hero of this story: ASP.NET MVC. The ASP.NET MVC framework implements the Model 2 MVC pattern for ASP.NET.

When you build an ASP.NET MVC application, you get all of the same benefits as you would get from any of the other Model 2 MVC frameworks. Most importantly, you get the benefits of a clear Separation of Concerns.

Because an ASP.NET MVC application exhibits a clear Separation of Concerns, an ASP.NET MVC application is highly testable. You can develop an ASP.NET MVC application using Test-Driven Development. Or, you can build all of your tests after the ASP.NET MVC application is written.

Because an ASP.NET MVC application exhibits a clear Separation of Concerns, an ASP.NET MVC application can be easily maintained and adapted over time. A clear Separation of Concerns makes it easier to modify your application at a future date without breaking existing functionality.

Unlike the other Model 2 MVC frameworks, however, when you build an ASP.NET MVC web application, you can take advantage of all of the rich functionality of the ASP.NET framework. ASP.NET MVC is still in its infant state. However, it stands on the shoulders of a mature technology.

ASP.NET MVC is part of the ASP.NET framework. This means that you can take advantage of the existing ASP.NET framework support for caching, security, session state, and Ajax. Millions of ASP.NET applications have been written with this technology so you know that the technology is mature and scalable.

You can build an ASP.NET MVC application using any language supported by the .NET framework. Typically, when people think of a .NET language, they immediately think of static languages such as C# or Visual Basic .NET. Realize, however, that the .NET framework -- with the inclusion of the Dynamic Language Runtime (DLR) -- will soon support many of the most popular dynamic languages including Ruby (IronRuby), Python (IronPython), and JavaScript (Managed Jscript). For example, soon you will be able to build ASP.NET MVC applications with the Ruby language and you will be able to take advantage of all of the features of the .NET framework.


In this blog entry, I’ve traced the history and evolution of the Model View Controller pattern. This blog entry had two goals. First, I wanted to clear away confusion over the meaning of the MVC pattern. People often use the word MVC to mean different things. In the context of web applications, the MVC pattern is really the Model 2 MVC pattern.

Second, I wanted to convey to you my excitement about ASP.NET MVC. The MVC pattern enables you to build applications that exhibit a clear Separation of Concerns and stand the test of time. ASP.NET and MVC is a powerful combination.


  • Hmm, you forgot the last step. Microsoft drops ASP.Net MVC for the simple fact that nobody cares.

  • How can you "discuss MVC in the context of ASP.NET" without at least a mention of Monorail? I appreciate your passion - in fact I share it - and kudos to everyone involved in making ASP.NET MVC a reality, but honestly, if ASP.NET MVC forms an evolutionary step in the history of the MVC pattern, then undoubtedly Monorail is fast becoming the "missing link".

  • Good article, it nicely highlights the differences between original MVC and the web-based flavor of MVC. Thanks!

  • @Kim -- Good point. Monorail has had a huge influence on MVC in the ASP.NET world.

  • great! mvc model for teach beginner

  • Since we are talking about Evolution, and since MVC's point is to offer a separation of concerns I was wondering if you might offer a tip about how to get a plugable MVC. For instance to start with a basic app that contains a little configuration and then little modules that can be dropped in the web sites bin folder be discovered and extend that web site with new routes, controllers, models and views.

    I'm really interested in viewing this done with ASP.NET MVC, it is the way I view the usefulness of mvc really coming together. Unfortunately the Rails movement keeps promoting a monolithic model that is not very extensible. You are forced to build one app and the replace files to get new values.

    It's just a thought that's been haunting me for some time now. I'd be really interested in hearing(reading) what you think of it ?

  • Great post. Thanks for the history lesson. ;-) My team is just getting started on MVC; this is a good historical intro.

  • ping bac from Samiq Bits: Model-View-Controller: a reference to its basics

    [... Today a post on the matter landed my RSS feeds, and thought it was a good start on the basics of MVC - it's always good to have a point of start and move from there.


    A remarkable thing to point is his distinction to the modern days of the pattern; just as American painter Jackson Pollock once said "new times call for new techniques". And it remains true to the way we solve problems in our industry.]

  • lazar, you bring up an interesting point. The nature (separation of concerns) of MVC is very suitable for plugin driven, composite web applications. But the ASP.NET MVC framework isn't quite there yet. The automatic discovery and routing could be handled already, and it would work if you want "one page=one controller". However, in composite scenarios, we may want "in the left columns, show all 'components' which implement ILeftColumnPlugin". RenderAction could provide this, but it's a feature which is heavily debated and it's also very buggy.

  • Regaring the MVC2, the diagram shows no relationship between model and view. I think, actually it should be a unidirectional line representing the view knows about the model, otherwise how would it represent the model without even knowing it?

    Say, a Customer class belongs to the model. Now, in a Customer data view, the view needs to invoke properties/methods on the model like, customer.FirstName. So, I see that the view needs some knowledge of the model to represent it.

  • The evolution of mvc.. Slap-up :)

Comments have been disabled for this content.