What is the best definition of MVC?

Question

I have been using the Zend Framework with an MVC configuration, read about Ruby on Rails and I plan to explore other MVC frameworks in Python (Django?). I really like the way it isolates some parts of the logic, security, and validation. But after just one year of using it I read an answer here saying that almost everyone has a wrong definition of MVC and that made me wonder: What is the Right definition of MVC and where could I read about the pattern and standard implementations?

Update: I understand we all know the BASIC definition (there's a model a controller and a view, the actions on the controller go to the view with some info after making something with the model) but I would love to know what is the definition you THINK everyone KNOWS and why is it wrong (and maybe that will explain to everyone where there could be mistakes, opinions, and of course what is your real point of view of this)

Answer 1

The most major mistake I find with peoples understanding of MVC is that they think the pattern encompasses more than it does. More specifically people often think:

• Model = DataBase
• View = HTML
• Controller = Business Logic and everything else.

This is often the way things work in a smaller application but reality MVC is a way to seperate the Business code from the presentation code. The Model does all the real business work. The views provide the look and feel, and the controller maps one to the other.

Answer 2

See Chapter 14 of the book: Patterns of Enterprise Application Architecture, by Martin Fowler.

The section on MVC starts with:

"Model View Controller (MVC) is one of the most quoted (and most misquoted) patterns around. It started as a framework developed by Trygve Reenskaug for the Smalltalk platform in the late 1970s. Since then it has played an influential role in most UI frameworks and in the thinking about UI design."

It also says:

"As I think about MVC I see two principal separations: separating the presentation from the model and separating the controller from the view.

...

Of these the separation of presentation and model is one of the most important design principles in software, and the only time you shouldn't follow it is in very simple systems where the model has no real behavior in it anyway. As soon as you get some nonvisual logic you should apply the separation. Unfortunately, a lot of UI frameworks make it difficult, and those that don't are often taught without a separation.

The separation of view and controller is less important, so I'd only recommend doing it when it is really helpful. For rich-client systems, that ends up being hardly ever, although it's common in Web front ends where the controller is separated out. Most of the patterns on Web design here are based on that principle."