Practical applications of Model View Controller?

Looking for simple examples of why it's useful.

[JAB Creations]

I'm not great with concepts but I comprehend practical application. I've read at least a dozen takes on the model view controller but every single time I read them they all fail to explain why they are useful to begin with.

When I was trying to learn relational databases the practical application that won me over was how simple it was to change the user's alias with a single query instantly changing it without modifying any existing code (presuming you already had relational tables setup). By using a JOIN it effectively converted the user's row id in to the associated name each time...change the name not the association. This is a real world example where I can comprehend what happens on both the client and server. A similar example for MVC would be greatly appreciated.

- John

[IanKelley]

As I understand it any database driven web application is technically a MVC. Where the three layers are:

1) HTML/Javascript/Images
2) Backend application (i.e. PHP)
3) Database containing content (i.e. MySQL)

So in other words it's a concept that was interesting 30 years ago before the web.

[Sekka]

The problem with MVC is that so many people have different interpretations, and to further the problem, most of them are right.

MVC doesn't have one strict meaning. MVC, at its core, is all about seperation.

The framework Symfony, for me, explains MVC. Let me try and explain how it works.

The model is the raw data and the processing of that raw data. For example, all the classes that communicate with your database (or any other database source for that matter) should be in your model. All methods to manipulate that data should be contained within these classes as they use business logic to format the data, e.g. $author->getBooks() would load all the books for a given author. This is part of the model.

The view is the HTML rendering. The view is passed data from the controller and formats that data how it needs to be presented to the user. Some business logic is used here (if you want to picky), but the majority is pure design driven. The idea is, you could completely reskin your website and never need to touch the controller or model. (However it never works out that way).

The controller is the guy inbetween. The controller determines what page you want to see, loads the relevant data from the model, and passes it to the view.

You'll find most apps will have the majority of their code in the model.

Hope this helps.

[coopster]

In the past MVC was known as IPO:

Input -> Process -> Output

Today? MVC ... but a bit backwards, should have been called CMV :)

Controller -> Model -> View

Input = Controller 
Process = Model 
Output = View

Sekka offers a good explanation, especially the part about it all being in the separation. A real world example could be something like your bank account. You can use a magnetic reader card or a teller that types in your account number (two different means of input) to access and work with (process) information in your account. The result could be a change in the information (storage) and/or a display/printout of the results (output). It's a very rudimentary example, but you can see that having separation can make the programming updates much easier and less costly. Adding new features or removing old features can also be much easier without disrupting existing flow.

[JAB Creations]

I'm going to try to break this down to as simple bits as I can...

So the first bit I'd determine the part of the site requested (blog, forum, etc). I'd determine all the data I need from $_GET and $_POST per page, etc?

The view would then determine how the page is put together...so ordering the information obtained from the model...so it would in the simplest terms be more of .= then echo... though this part I seem to be vague about most? Perhaps I would determine the information to be assigned to classes and the XHTML templates I would need for the third part of MVC?

It seems the controller is simply an XHTML output file or template files that echo out information assigned to classes in example...?

I'm trying to approach the concept from a practical application or at least how I would use PHP to construct a page. Once I know the specifics I should be more closer to understanding why MVC is useful. Thanks for your replies.

- John

[IanKelley]

http://en.wikipedia.org/wiki/Model-view-controller [en.wikipedia.org]

MVC is often seen in web applications, where the view is the actual HTML or XHTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML. Finally, the model is represented by the actual content, which is often stored in a database or in XML nodes, and the business rules that transform that content based on user actions.

[vincevincevince]

Today, the MVC model has changed slightly; the controller now holds more business logic than would previously have been the case, however the model is more modular and object oriented.

1. Classes describe object-roles, contain their functionality and their database interaction: validation, consistency, processing, insert, update, fetch, etc.
2. Control/logic scripts are simple structures often similar to select...case constructs - they take rudimentary instruction from the user (if 'submit add form' then if (!$a=new userAccount($_POST)) $template->parseError($a)) else $template->set('acc_created');
3. The template engine generates the view from templates plus the output of the control/logic scripts - this is what the user sees

Technically/traditionally, 1 and 2 combine to form the model, the template engine of 3 is the controller and the template files the view; however such an arrangement denies the ability to enforce separation of business logic and object logic.