johnrcornell Posted May 18, 2007 Share Posted May 18, 2007 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 Quote Link to comment Share on other sites More sharing options...
Nameless12 Posted May 19, 2007 Share Posted May 19, 2007 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! Quote Link to comment Share on other sites More sharing options...
johnrcornell Posted May 19, 2007 Author Share Posted May 19, 2007 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? Quote Link to comment Share on other sites More sharing options...
Nameless12 Posted May 19, 2007 Share Posted May 19, 2007 Models should not be creating instances unless its object composition, the controller is called the controller because it controls everything. Quote Link to comment Share on other sites More sharing options...
johnrcornell Posted May 19, 2007 Author Share Posted May 19, 2007 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! Quote Link to comment Share on other sites More sharing options...
Nameless12 Posted May 20, 2007 Share Posted May 20, 2007 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 Quote Link to comment Share on other sites More sharing options...
seddonym Posted May 22, 2007 Share Posted May 22, 2007 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. Quote Link to comment Share on other sites More sharing options...
Buyocat Posted May 28, 2007 Share Posted May 28, 2007 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.