Page 1 of 1

MVC question

Posted: Tue Dec 27, 2005 7:30 pm
by harrisonad
hi,

been reading this article: http://www.phppatterns.com/docs/design/ ... er_pattern
and looking at the example between the ProductView and ProductController classes, I am not convinced why there is the need to create the ProductController class extending the ProductView class, only because of the modified constructor.

Re: MVC question

Posted: Wed Dec 28, 2005 5:41 am
by foobar
harrisonad wrote:[...] I am not convinced why there is the need to create the ProductController class extending the ProductView class, because of the modified constructor.
Ok.

Where's the question?

Posted: Wed Dec 28, 2005 7:10 am
by Ree
:lol:

Posted: Wed Dec 28, 2005 7:24 am
by Charles256
maybe he wants to be convinced?

Posted: Wed Dec 28, 2005 1:57 pm
by alvinphp
One reason is that for larger projects the person working on the View is not a programmer so you want to keep the Model and Control seperated from the View. This way you can both work on the same module without messing each other up toooo much.

Posted: Wed Dec 28, 2005 6:21 pm
by harrisonad
Thanks, alvin for serious reponse. Lot of jokers have been sticking to this forum ever since.

Well, the word separated always confused me since the controller, as in that example, depends on the view for its methods and properties.

My first though of MVC ppattern is that these components (models,views and controller) got stand-alone classes, rendering the thought of separation.

Is it?

Posted: Thu Dec 29, 2005 2:31 am
by Jenk
This is what threw me when I first looked at MVC.

Whilst the term is separation - it is not a dictionary definition.
Separation in MVC means using objects to create common paths and methods (aka patterns) to achieve a goal.

e.g. - a data source object.

Now, a mysql class for example, is not going to be able to do much at all in stand alone, but it allows the logic developer to have easy to use methods to gain access to data:

Code: Select all

<?php

$db = new MySQLClass();

$db->connect('host', 'user', 'pass', 'db');

$rows = $db->fetch('SELECT * FROM `table`');

?>
Now.. this is where the Separation comes into it - what if, for example, the hosting company switches databse software to Oracle?
Well - the Logic Developer will not have a huge amount to change - apart from any RDBMS specific SQL, hardly anything at all:

Code: Select all

<?php

$db = new OracleClass();

$db->connect('host', 'user', 'pass', 'db');

$rows = $db->fetch('SELECT * FROM `table`');

?>
So providing both classes share method names, then the logic developer will only have to change the object class, and that is it.

So as you can see, this will allow the developer of the data object and the logic developer to work independantly of one another - if the data object needs tweaking or a huge revamp, this can be done without the logic code being changed at all and vice versa.