Understanding Model-View-Controller

Not sure if you can compare 3 tier or N tier architecture versus MVC.

MVC is representation of data via a patern where the same data can be viewed different as manipulated by the controller, where 3 tier or N tier architecture is a method of separating out different layers or coding. MVC could use 3 or n tier architecture coding pattern if needed.

MVC may be used when you have a part or parts of your system that will need to be represented with different views or different reprsentations.

For example, I want to view object X as a:

As a Thumbnail
As a node in a tree
As a preview
As a 3D image

I wouldn’t get too strung out over MVC, just because your application implements it doesn’t mean it is better or bug free. MVC adds abstractions to the code which is general make it more difficult to understand. Implementing MVC in your application depends on the need to represent the same underlying data structure with different views. If you don’t have that requirement, then why consider implementing MVC?

This is one of the best things I’ve read this year. We could replace most of the MVC chapter in Head First Design patterns with this blog post and it’d be an improvement.

Where’s the donate button on your blog? I want to pay for this content.

I’m also happy to see that you’re checking out ASP.NET MVC and looking forward to any other reactions you have to it.

You chose a very poor CSS “controller” for your example ;/

It took me some time to get my head around MVC. It’s actually several patterns together. But once you start to use it it all drops in place,

This may be an old post, but it was quite an interesting read on MVC, which I had only recently started reading about. After a thorough read through all the comments, I’ve come to a rather simple, but viable conclusion about how the MVC can be interpreted safely. I will however 100% agree that the concept is open to interpretation. So here’s my view:

The Model can be viewed as your database itself, with the information in it, along with the server-side code whose sole job is to retrieve, update and alter subsets of that stored information. This could include also and low-level business logic that would be commonly or regularly performed on the data before being used.

The Controller would essentially be the middle man between the Model and the View, whose job is to respond to user interaction, decide what the interaction was, decide how to handle it, and what to do with the information/interaction retrieved from the user. The Controller would take that information and often contact the Model to either update, or retrieve a subset of data based on the user’s interaction. The Model would respond with the appropriate subset or possibly no subset if it was an action query of some sort, and return control to the Controller. The Controller would then take that subset of data, if available, and direct the user to the appropriate View, where the data can be presented to the user.

The View would, in my opinion, be the HTML, CSS, Javascript, etc that creates the user interface. Anything that creates the Presentation of Data is the responsibility of the View. Upon user interaction, the View will direct control to the Controller, and the cycle goes on.

There is one little area where this concept of separation isn’t PERFECT. Javascript can be used for a couple reasons: 1) It can be used as a purely aesthetic apparatus in building page elements on the fly 2) It can also be used to do Client-Side Validation and HTTP Request for Ajax Driven Web Applications. In this case, Javascript can do partly the job of the Controller and the View. This presents the break in the PERFECT philosophy of separation in the sense that one would like to keep all of his/her Controller code in one place and View Code in another. The job of the Controller would essentially be split into two different areas, as would the View. This of course is the natural order of things in terms of building rich web applications, so it comes of no surprise, so my best suggestion in this case would be to have any Javascript code used for aesthetic reasons separated from any JS code used to contribute to the job of the Controller. In this way, code still remains clean, scalable, and easy to debug.

My best example of an MVC implementation without Javascript in the mix would be as follows:
I stumbled upon a set of classes I used in part to complete a school project from which you instantiate a few basic PHP Objects: The Database Object, The Session Object, and the Form Object. Also, there was a controller.php page that intercepted all form submissions and utilized any Controller Objects as needed. The Controller objects would in turn communicate with the Database Object.

For example:
Start VIEW:
A user would be presented with a Registration Form. Upon submission, as with every form submission, control is directed to controller.php.

Start CONTROLLER:
controller.php makes use of the Session Object’s “Register” Method. This method would validate the user’s input, build the Form Object with Input Values and Errors. If no errors were found, control is directed to the appropriate Method in the Database Object.

Start MODEL:
The Database Object would update the user table with the new values, and return control to the Session Object, giving it a response of Success or Failure.

Start CONTROLLER:
If the update to the Database was successful, the Controller would decide which View to present to the user, along with a “Registration Successful” message. In this case, control would likely be directed back to Registration page.

Start VIEW:
The Registration page would take the Success message it received from the Controller and display it to the user, and most likely hide the registration form. From here, the process starts over based on the users next interaction.

So as a conclusion, the MVC is no more than a documented structure on which most good programmers already develop applications. So the separation concept behind it is not an unfamiliar one at all. It is a great concept and can be effectively implemented in MOST applications, but not all. The advantage, as I see it, is the ability to present a developer with a Programming Paradigm to keep in mind as he/she develops their application. If the developer follows a similar sort of structured separation, they will inevitably end up with more easily maintainable and scalable code. That being said, the programmer is not limited to this exact flavor of MVC, but rather can build his/her own conception of this sort of separation and as long as it results in organized, scalable and maintainable code, I’d say the odds are good of it representing a Valid form of MVC.

So if this thread is still even remotely alive, please let me know what you folks think of my interpretation. Keep in mind that I’ve only been programming for about a year if destructive criticism comes to mind :stuck_out_tongue_winking_eye: - Zach

IT seems only limiting to me, that we wish for development to have a standard model like MVC. I guess in if we don’t mind leaving our imaginations out of it, then it would be nice to nail down a concept like MVC; we could go about our development with confidence that the correct approach was taken and professional job was done. This way we don’t have to toil over figuring out a tailor made model for each new application we build. By trying to define best development strategy in terms of some fundamental model like this MVC, I believe we impose great and unnecessarily restriction upon the possibilities. Perhaps views should be smarter and control more static? Maybe I want to alter your model with my app’s view? Perhaps I need my controller to be dynamically generated based on the nature of your view. Now your view would serve as my solution’s model and promote my controller into service as a view. Maybe this smart, on-time view of mine could now model for some other app’s controls. Perhaps we could come up with a new way to aggregate application functionality regardless of API or even in the absence of one. But, no such fun is likely to happen, if we’ve accepted a restricting “best standard” for our work to feel professional.

The URL is not correct anymore. The correct URL is http://www.object-arts.com/downloads/papers/TwistingTheTriad.PDF

I prefer to think of things in tiers when dealing with enterprise web based applications

  • Data tier - dumb data store, no logic except for constraints.
  • Service tier - provides an API and protocols to interact with the data tier and does the actual manipulation of the data
  • Presentation tier - connects with the service tier and not have any data on this level.
  • Support tier - provides extra support for the presentation tier such as enterprise caching and enterprise search, different from service tier as it is usually external products rather than home-built.

Each tier would have their respective contracts for communication with each other.

For presentation tier just use model-view-whatever. It is just important that you have a model that is separate from view and how you interact with it depends on whatever technology stack you are using.