MVC/OO theory

[johnrcornell]

Hi,

 

Seeing the frequency of this on this board I hope no one is rolling their eyes at my topic. I posted this at comp.lang.php and got 0 responses, so I'm thinking it was the wrong place to ask. Reading some of the explanations here http://www.phpfreaks.com/forums/index.php/topic,138169.0.html it sounds like the model is just where your database abstraction/ORM takes place. Here was my original post:

 

---

 

Greetings All,

 

I had a question about OO implementation in the MVC pattern that is

directed at anyone who feels experienced with it.

 

My fuzziness comes from trying to learn OOP and MVC at the same time,

coming from a procedural background where I used neither. I promise

I'm not a dummy, and my logic skills are very strong, but this really

is a whole new world for me.

 

From my study of MVC the role of the controller component is most

confusing to me. Traditionally, it seems that the controller was used

in os-based software to manage input from the user, the actual data

type handling, etc, where on a statically typed language or os-based

software that is more of an issue. Reading a Developer's Library book

called "Advanced PHP Programming" by a guy named George Schlossnagle

(who seems like a fairly bright programmer) the assertion is made that

the controller is irrelevant to the web because the browser handles

all the input. Obviously that's not the stance of a big part of the

community, as frameworks like Symfony, etc make a big deal out of the

controller. The PHP-framework implementation of a controller seems to

be more abstract than in os-software.

 

So my question is, if I were to implement a controller, what I gather

is basically that the model component would be comprised of only

classes with no procedural execution, and that the controller would

primarily be responsible for all instantiation of the model's business-

logic classes? Is that the idea? I realize I may be asking for an

answer that involves personal preference but if you have one, please

let me know. Thank you in advance!

 

Ricky

[Nameless12]

The trick is to not get caught up with peoples implementation. Controllers are not something that make a site mvc, controllers are just one of the components. And controllers do not need to be an object. The controller is called the controller because it controllers everything, the view is the GUI that uses data gathered from the model.

 

It is really quite easy to understand the parts that may confuse you is all the routing\bloated controllers that you are seeing in all the frameworks.

 

My fuzziness comes from trying to learn OOP and MVC at the same time

There is a simple solution to this, learn oop fist!

 

 

 

 

 

 

[johnrcornell]

Hey, thank you for your response! I think I've got a little better grip on it now. I have a rephrase of the question-

 

Is it correct to say that in a properly-designed MVC implementation, no instantiation would occur in the model outside of a class?

[Nameless12]

Models should not be creating instances unless its object composition, the controller is called the controller because it controls everything.

[johnrcornell]

So the object definitions are collectively the "model"

All that class-external instantiation and logic is the "controller"

And the easiest to understand, the system output is the "view"

 

I think I've got it. Thank you!

[Nameless12]

Try not to use golden rules, you could as easily use functions as opposed to classes.

 

//here is my own little summary for you

Controller: Should route to a specific area where you can `control` things

Model: classes\functions\generic things, there should never be output here unless you are debugging

View: the template file where the Controllers data is passed and displayed

 

 

[seddonym]

A few months ago I realised that I would be best off producing a site using an MVC framework but got pretty bogged down in how to implement one.

 

The advice I would give is: don't bother trying to write one.  At least not yet.  The first thing you should do is use someone else's MVC framework.  There are a few around and they are designed to give you easy (ish) ways of creating MVC based sites.  I find it difficult to believe that someone who's never made an MVC framework before would come up with a better one than an existing one that is already out there and is tried and tested.  The only one I've used is CodeIgniter, which is apparently a good choice for beginners.  Cake is also very popular.

 

All they are (and I'd wish I'd known this earlier) is a load of php files in a prepackaged directory structure that you upload onto your server.  You then add php files to the correct directories,  according to the format decided on by that particular package.  For example, with CodeIgniter you put controllers in the 'controller' directory, models in the 'models' directory, views in the 'views' directory.  (Who would've thought...)  You can also edit settings in various configuration files.

 

CodeIgnitor's documentation is a pretty good way into the whole thing.  You can start using it without understanding the nuts and bolts of how MVC works (just how it is used) but you can look at all the source code if need be.

 

Hope that's useful.

[Buyocat]

Each element in MVC can get different emphasis, and I think it's fair to say that for web programming the Controller has reduced responsibility simply because the notion of an event is absent (at least until you introduce javascript).  That said I would say the controller's responsibility is to take some amount of user input and generate a model/view with it.  For instance the url, example/user/fetch/1 might be unfolded by the controller to generate the user model and call the fetch model with 1 passed as a parameter.

 

The real question is whether to implement a page, front, or application controller.  I'll leave off there unless you want to discuss if further.