In english, what really is model-view-controller?

Question

I develop in php and all the tutorials or pages such as wikipedia that I see don't really explain what mvc really is.

In my understanding so far mvc is a file structure which includes your classes, websites with their html, external style sheets or 3rd party plugins (seperated in its own folder).

I have created a structure such as this which help me create new websites so that I don't have to make anything from scratch. Look at this and tell me if it's a mvc or something else.

[admin] - administration pages
-[css]
-[js]
--default js script , then including other js plugins that I've found.
-[classes]
--login class,pagination class, other 3rd party classes that I've liked.
-[includes]
--config.php (database connection)
-[lang]
--english.php(contains an array of english words that are linked to pages)

-index.php

As you can see I've organized classes and other scripts in their directories and I can include them into my project as needed based on the projects requirements. Would this type of setup be considered an mvc?

The definition itself as you know is:

m-model(data) which by my understanding is the data that is displayed on the page and either grabbed from the database using classes or from an array

view(visual) the design of the page such as coming from the stylesheet, or javascript, ajax and other types of interaction that is written in the page and including images.

controller - no clue what this for, and if you can please explain.

So based on the structure of files that I have created, can you explain it to me so that I get a better understanding (if you don't mind that is).

Answer 1

Have you checked the 'Pattern Description' section on Wikipedia's description of MVC?

Answer 2

In short:

A Controller is where all of the logic for the page happens. It is the first thing that's hit in the lifecycle. The controller sets up some kind of object - this is the model.

The controller then passes the model over to the view, which uses the model to display the data in some way

Answer 3

MVC architecture is not exactly a structure of source files.
They call it "design pattern" which means that you are creating all the logics and code in your software trying to have 3 modules as independent as possible so if you change one of them (model/view/controller) you do not have to change all of them.

usually you can distinguish source files either by creating three folders for each of them or by using prefix in files:

ModelXXXX.ext
ViewXXXX.ext
ControllerXXX.ext

As for the meaning of each of the modules:
- model is responsible for storing and manipulating data
- view can format, output and represent data
- controller is usually responsible for user input
it is just IMHO. Maybe someone can explain it easier.

actually this on is a good article: http://en.wikipedia.org/wiki/Model–view–controller

Answer 4

A quote from c2.com:

An easy way to understand MVC: the model is the data, the view is the window on the screen, and the controller is the glue between the two.

Model-View-Controller is the concept of seperating your data (and how you get it) – the Model, and isolate it from the manipulation – the Controller, and presentation - the View.

• A model is an object representing data or even activity, (a database table or even some machine process).
• A view is some form of visualization of the state of the model.
• A controller offers actions/methods to change the state of the model.

c2.com is the best place to find about design/computing patterns like this one.

Answer 5

The MVC pattern is a strategy for handling complexity by suggesting a way to organize your code by its function within the system. By organizing your code in this particular way, you can make it modular, since the code that is caring for your core "business logic" isn't also making assumptions about how information is being rendered on a user's screen, and the code that draws stuff to the screen isn't assuming things about what kind of data structures you're using in your database. By having a "controller" layer inbetween, you decouple the two modules, and make them seperable without breaking the functioning of the program.

By organizing code in this way, it provides you a strategy for locating bugs, diagnosing problems, and giving you a clearer path for adding new features.

Answer 6

Let me summarize the three parts of MVC again and map them to your directory structure and some general examples

The Model holds the state of your applicaton that should be displayed (or manipulated) by the current user request. In most cases this are some database objects which represent real entities: a user object which was just registered, product A which the user U wants to see (here A and U would both be part of the state) or the transaction data of a finished purchase (e.g., the user, the product, the credit card clearance information etc.). But it's not restricted to database objects, it could be, as you pointed out, an array of calculation results.

From a programming point of view this would translate in separate classes - probably also stored in a separate folder - which are only responsible for holding the state data and provide simple operations to manipulate it. A simple Example would be a Product class which can be filled with data from the database and performs price/tax/discount operation on the product it represents (even though it could be argued the calculation should be in a separate class)

In your example this would probably some of the classes in your classes directory.

The Controller is the main logic that handles the user requests which is creating or retrieving the Model data (e.g., through a database request or performing a calculation) and forwarding it to the View. This part of the code is also often referred to as business logic. The controller of a web application usually looks like this: Check authorization of user requests to access this page, load required objects from database, perform operation on objects, move objects to view, clean up.

This would translate into the PHP page which is invoked by the user which is then forwarding the data to a separate template engine (the view) or another PHP page for display. In Java this would be a Servlet (or a framework component like a Struts Action).

In your example, this might be the index.php, but if your application is a little bit more complex, you probably want to have a separate PHP page for each action your users want to do, like add_comment.php, show_product.php etc.

The View is the logic that will then display the state data which was passed along by the Controller. In a "pure" MVC world, this should not contain any business logic, do not perform any computation etc. but simply take the data and put it into certain areas of the UI which the user will see.

Again, for PHP this could be a template page (in Smarty) or a separate PHP file which only contains echo statements and HTML, in Java this are mostly JSP pages etc. All the JavaScript, CSS, images and other files which are used to create the final page that is sent back to the user are also considered part of the view.

In your example, this would obviously be the css and js directory, but you probably mixed the view and business logic in your classes and/or index.php, I guess.

The whole idea of MVC is separation of concerns, so that the code is reusable (the model data can be used by many actions) and easy to maintain, as you don't need to touch the controller if you want to change some colors and layout in the view.

So it doesn't really matter how you create your directories or files, if your application is MVC based depends on how you structure your code.

Answer 7

MVC is an architectural pattern that attempts to achieve a clear separation between the code that represents a real-world view of an application, and the way a user interacts with the application.

A quick summary and example might be:

Model: Code that represents the real world, and how it operates. You might have a Car class that contains a drive() function and a start() function. The Car class models a real-world car. Models have no knowledge of Views.

View: Code that presents the application to a user. HTML, CSS and Javascript all make up part of the view layer. You might have a template file that takes in a Car object and renders a nice representation to a web browser.

Controller: Code that takes user input and decides what to do with it. You might have a CarController class that receives data from a web form. Based on the input, you might call Car.drive(), or you might call Car.start(). The Controller makes these decisions.

By separating application logic into the layers of MVC, you separate the concerns of the code, which is a desirable property of good object-oriented programming. It improves code re-usability, and enforces the Don't Repeat Yourself (DRY) principle.

It's therefore more than a file organization technique, it's an architectural style that guides how you create your code in order to achieve a well-designed and easily maintainable application.

Answer 8

I couldn't really understand MVC until I experimented with it, this why I recommend that you learn any of PHP MVC frameworks, and play with it. I learned MVC with CakePHP but I personally recommend CodeIgniter for it simplicity, no-magic approach features.

Answer 9

Let's take a video game example, using Pac-Man.

The "Model" of the PacMan game is the data that represents the maze, and the dots. This model knows how to do certain actions, such as moving Pac-Man up. It also knows the rules of the game, and how things should behave.

The View is the screen - how the model is presented to the user. It understands the data that the model puts out, but has no concept really of how anything should behave. It is only responsible for rendering the data, not calculating the data in any way.

The Controller is the code that takes the player input from the joystick and puts it into terms the model can understand. It takes "joystick moved up" and translates that into "move Pac-Man up". It doesn't have to understand what "move pacman up" means, or even how quickly pacman should be moved up. It just translates the user gestures into commands that the model understands.

The advantage of this style of architecture is that it clearly separates the responsibilities of the pieces, so that they can be changed orthogonally.

For instance, you could make a new super-3d renderer for Pac-Man, just by changing the View. The underlying Model would remain the same, and the Controller could remain unchanged as well (assuming that it was still appropriate, of course).

At the same time, you could make Pac-Man be controlled by a keyboard or even network messages by changing the Controller, without having to touch the View or Model.

You could also change the behavior of the game, making regular dots act as power pellets, or making Pac-Man twice as fast, by changing the Model - the View and Controller wouldn't have to change at all.

Answer 10

Traditionally, a .php page is doing one thing and one thing only. It establishes a database connection somewhere at the top, gets data, massages it, outputs it. It's one solid block. You have a hard time re-using components in it.

Usually you tend to at least "outsource" the database connection part into a separate file (or so I hope :)). That's basically a rudimentary model.

You might also put a few bits and pieces of repetitive HTML code into separate files to reuse them, creating very basic views.

The logical conclusion of this separation is the model, view, controller paradigm. The model only cares about data, it has nothing to do with page flow, user interaction and such. The view only cares about output, it displays whatever data it is being handed in its particular fashion. So what's left is the part that needs to do some logic, that's the controller.

Ideally the controller can take any data from any model and stick it into any view. Outputting an HTML page in RSS or PDF format is simply a matter of switching out the view part. The same PDF view might also be used be a completely different controller sticking in completely different data.

You could switch your database backend to an XML file based backend simply by swapping in a different model, and none of the other parts need to care.

It's all about reusability, reusing the same data in different contexts, reusing the same presentation for different data, all with a minimal amount of code.