SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 31
  1. #1
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Grr. Need some help with models in MVC

    OK so,

    I am a bit confused about the MODEL part of the MVC design.

    Basically, what I have done is made it a gateway that basically abstracts the DB and provides some easy functions to get data (ie getCarName($id).. etc).

    So, who calls the model? and where does the data from the model go?

    Does the controller call the model, and then it returns the data to the controller, which passes it to the view again?

    This is what a few posts over at CodeIgnitor forums suggest, but from the MVC designs I've seen, the Model should be interacting directly with the view...

    Am I missing something?

    Please help me!

  2. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It depends on who you ask.
    The traditionalists will say that the controller updates the model and the view reads from the model. Thus both have direct access to the model, but for different purposes.
    A more common interpretation is a design, where the controller acts as a mediator between view and model. In this design, the view either asks the controller for the appropriate model, or the controller knows which models, the view needs and gives it to it. The latter means, that the controller and view become very dependent on each other.

  3. #3
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tankbott View Post
    Does the controller call the model, and then it returns the data to the controller, which passes it to the view again?
    No, in any case the model should be completely ignorant of the other two components.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  4. #4
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have the following flow structure


    > FrontController (decides what module to pass onto)
    > InterceptingFilter (performs various operations on the requests like authentication)
    > Module/ActionController (interacts with the models gets/sets data to them)
    > View (data passed here from the Module controller)

  5. #5
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "No, in any case the model should be completely ignorant of the other two components."

    How does it's data get passed then?

  6. #6
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    It depends on who you ask.
    The traditionalists will say that the controller updates the model and the view reads from the model. Thus both have direct access to the model, but for different purposes.
    A more common interpretation is a design, where the controller acts as a mediator between view and model. In this design, the view either asks the controller for the appropriate model, or the controller knows which models, the view needs and gives it to it. The latter means, that the controller and view become very dependent on each other.
    Ahh, that makes sense. Which do you think is better suited for a web environment? More flexible, extensible? Allow for more rapid development?

  7. #7
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tankbott View Post
    "No, in any case the model should be completely ignorant of the other two components."

    How does it's data get passed then?
    Two things, the controller and view are aware of the model. The model may also trigger events which are handled in either the controller or the view that way, two way communication remains possible, while still having the model completely decoupled.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  8. #8
    SitePoint Enthusiast
    Join Date
    Mar 2007
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tankbott View Post
    Ahh, that makes sense. Which do you think is better suited for a web environment? More flexible, extensible? Allow for more rapid development?
    I like the first one personally. Easier to re-use views that way. Also when there is a change in the view you only have to update the view. You dont need to go back in the controller and fetch the data needed for the modified view.

  9. #9
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Jasper, I think I am catching your drift but still do not completely understand. Do you think you could provide a quick example or reference/link?

    Thanks!

  10. #10
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tankbott View Post
    Jasper, I think I am catching your drift but still do not completely understand. Do you think you could provide a quick example or reference/link?

    Thanks!
    Please note that the implementation of all these classes are there only for illustrative purposes; the example is here only to display the interaction between the model, view and controller. So, to restate what I said earlier, the model sends events usually to the view, though everyone can listen, you shouldn't care about that really, but it's usually the view that needs the data. And the model also doesn't know about the controller; everything the model needs will be filled in by the controller. We now have a completely decoupled model class; and have encapsulated the things that change most often, in my humble experience, in the controller and view classes.
    PHP Code:
    <?php
    class acontroller{
        public function 
    handle(){
            
    $view = new view;
            
    event::register('on_avalue_change'$view);
            
            
    $model = new amodel();
            
    // controller must be aware of the model
            // but again, the models doesn't know about
            // the view
            
    $model->do_some_calculations(intval($_GET['input']));
            
            
    $view->render();
        }
    }

    class 
    event{
        private static 
    $listeners;
        
        public static function 
    register($event_name$handler){
            
    self::$listeners[$event_name][] = $handler;
        }
        
        public static function 
    notify($event_name$object){
            foreach(
    self::listeners[$event] as $handler){
                
    $handler->{$event_name)($object);
            }
        }
    }

    class 
    amodel{
        private 
    $avalue;
        
        public function 
    do_some_calculations($avariable){
            
    $this->avalue =  sqrt($avariable) / log(2) * 12;
            
            
    // simple naive implementation that is here
            // just to illustrate a point; look into
            // the observer pattern more for better
            // implementations.
            // this completely separates the model from
            // the view while still allowing the model
            // to notify the view of changes.
            
    event::notify('on_avalue_change'$this->avalue);
        }
    }

    class 
    aview{
        public function 
    on_avalue_change($avalue){
            echo 
    $avalue;
        }
        
        public function 
    render(){
            
    // do whatever here
        
    }
    }

    $controller = new acontroller();
    $controller->handle();
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  11. #11
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aso View Post
    I like the first one personally. Easier to re-use views that way. Also when there is a change in the view you only have to update the view. You dont need to go back in the controller and fetch the data needed for the modified view.
    I'm thinking it's more a matter of degree. The view has to know about the model somehow, and in a web context, only the controller can make the view aware of the model By having the controller pass an appropriately large chunk of the model to the view, you can get the effect you mention. If the chunk is too small (=doesn't contain the data the view needs), you'll have to change the controller to make the change.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  12. #12
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the replies. Does anyone know of any frameworks that implement this pattern that I can take a look at to get a better understanding of the observer pattern?

  13. #13
    SitePoint Enthusiast
    Join Date
    Oct 2006
    Posts
    37
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    The view has to know about the model somehow
    All the view needs to know is which view am I displaying, and what data will I use. The model generates those parameters, but there is no need for a coupling there.

  14. #14
    SitePoint Enthusiast
    Join Date
    Mar 2007
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    I'm thinking it's more a matter of degree. The view has to know about the model somehow, and in a web context, only the controller can make the view aware of the model By having the controller pass an appropriately large chunk of the model to the view, you can get the effect you mention. If the chunk is too small (=doesn't contain the data the view needs), you'll have to change the controller to make the change.
    Well maybe my naming of a View is off. My view basically does this: It gets the data from the model (the model doesnt have to be from a controller, it can though). Sometimes the view also needs parameters from the controller. But thats it here. The View here does all the work of getting the data and formatting it properly. After it has done all that it gets sent to a template.

    My controller basically just validates the request and does mutations on the model based on the request. It also calls the view it needs to display in the end. So I guess im not really using MVC since my View doesnt actually know the controller. I havent really seen the need for it because the view is the last stage of building the page anyway.

    In terms of responsibility it falls in the View layer so i called it that . So in the end i rarely have to change my controller if i want to display something extra or new. I simply modify the specific View.

    Perhaps i should call it something else...

  15. #15
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    The view has to know about the model somehow, and in a web context, only the controller can make the view aware of the model
    I either don't get that, or I disagree. The controller selects the view, but the controller needn't know which model, the view needs access to. The controller only needs to know which model it itself needs access to.

    Both the controller and the view will often need access to the http-request, to make their decisions. For example, a primary-key may be part of the URL. There will often be some kind of mapping from the request -> an internal meaning, and this is usually done in the controller. Since the view needs to generate URL's, it can be said to depend on the controller.

  16. #16
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    I either don't get that, or I disagree. The controller selects the view, but the controller needn't know which model, the view needs access to. The controller only needs to know which model it itself needs access to.
    I find this a bit contrary to your design of konstrukt. That framework doesn't concern itself with models, of course, but there doesn't seem to be a way of injecting models into a controller and k_Controller::GET() has no arguments, so it seems to me that the most convenient thing is something like...
    PHP Code:
    function GET()
    {
      
    $model = new My_Model_Foo();
      
    $this->bar $model->getBar();
      
    $this->render('../templates/foo.tpl.php');

    Since it's the controller that renders the view -- that is, there's no object wrapping the view -- the view can be
    (i) neither responsible for selecting a model other than by virtue of receiving variables from the controller and making reference to them in its php code fragments; nor
    (ii) instantiating one (and the latter would seem to go against what many have argued should be done in an MVC-style app).

    Can you elaborate further?
    Zealotry is contingent upon 100 posts and addiction 200?

  17. #17
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    I either don't get that, or I disagree. The controller selects the view, but the controller needn't know which model, the view needs access to. The controller only needs to know which model it itself needs access to.
    I guess this shows how hard it can be to communicate when everyone has slightly different designs. You say "which model", implying several, while others say "the model" as if there were only one.

    You say the controller selects the view. What object instantiates the view? Some kind of DI container? And why does the controller need access to a model?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  18. #18
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aso View Post
    Well maybe my naming of a View is off. My view basically does this: It gets the data from the model (the model doesnt have to be from a controller, it can though). Sometimes the view also needs parameters from the controller. But thats it here. The View here does all the work of getting the data and formatting it properly. After it has done all that it gets sent to a template.
    I think you're using a thicker view than I tend to use. I prefer a thin wrapper around a template.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  19. #19
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, so about the observer, would you need an observer for every view then?

    Also, in your controller, you register all the variables that the view needs to the Event object. When you make a change to your view, (ie add a new field), you need to change the controller as well to basically add a new variable to listen for changes. Isn't this as much work as passing the variables right to the view, instead of having it go through this Event class?

    Enlighten me!

    Thanks for the help.
    Last edited by renderstream; Jan 31, 2008 at 07:17.

  20. #20
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    I guess this shows how hard it can be to communicate when everyone has slightly different designs. You say "which model", implying several, while others say "the model" as if there were only one.
    Yes, I used model in plural, as meaning model components. I agree that using model in that way is a bit wrong, but it has become so common, that I didn't even realise I did it.

    Quote Originally Posted by auricle View Post
    I find this a bit contrary to your design of konstrukt.
    That's a good observation. Konstrukt isn't centered around a strict MVC separation. It doesn't make much assumptions about the model, although it's implied that it should be kept in a separate layer. On the presentation (v+c) level, it has components as the primary unit. A component has both controller and view roles. There is nothing stopping you from further dividing a component into separate view and controller, but it's not something Konstrukt does for you. This is by design; Within the presentation layer, I find it much more valuable to divide the application into components first, layers second, than the other way around.

    Quote Originally Posted by dagfinn View Post
    You say the controller selects the view. What object instantiates the view? Some kind of DI container? And why does the controller need access to a model?
    The controller would need access to do any updates. Naturally, that may not always be needed. Just like the view wouldn't always need access to any model level components. And yes, I was deliberately avoiding the issue of wiring. However ...

    Quote Originally Posted by auricle View Post
    PHP Code:
    function GET()
    {
      
    $model = new My_Model_Foo();
      
    $this->bar $model->getBar();
      
    $this->render('../templates/foo.tpl.php');

    Since it's the controller that renders the view -- that is, there's no object wrapping the view -- the view can be
    (i) neither responsible for selecting a model other than by virtue of receiving variables from the controller and making reference to them in its php code fragments; nor
    (ii) instantiating one (and the latter would seem to go against what many have argued should be done in an MVC-style app).
    How the view (and controller, for the matter) gets access to model components, isn't an aspect of MVC per se. This is something, which is orthogonal to the layers. If you use dependency-passing, then there are some hurdles, since the dependencies must be passed through the layers. Because of this, most MVC-layered applications, will tend to offer some kind of solution to this problem. Different patterns exists; Global variables are the most crude way and dependency injection containers are perhaps the most sophisticated. Konstrukt uses a registry/factory solution. I have been experimenting a bit recently, with replacing this with a di-container instead, but the current solution actually works fairly well.

  21. #21
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    The controller would need access to do any updates.
    Of course. My brain short-circuited for a while.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  22. #22
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK so is the model basically a bunch of getters/setters as a container to hold data? OR does it access the database to get this information??

    If it is the latter (ie, the Model is basically an object that has abstracted and premade db calls , ie getAllUsers()) then how would the view get information that does not require accessing the db. For exampple if the user entered 1+1, the controller would calculate the answer as 2 and the view needs to display this?
    Last edited by tankbott; Feb 3, 2008 at 21:18.

  23. #23
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tankbott View Post
    OK so is the model basically a bunch of getters/setters as a container to hold data? OR does it access the database to get this information??

    If it is the latter (ie, the Model is basically an object that has abstracted and premade db calls , ie getAllUsers()) then how would the view get information that does not require accessing the db. For exampple if the user entered 1+1, the controller would calculate the answer as 2 and the view needs to display this?
    Most PHP applications are about content management. As such, data access usually plays a big part. The model deals with this part, but it isn't just about this. Basically, the model is the logic-part of your application. If you have logic, which doesn't involve data access (Such as adding to numbers together), then that would belong in a model layer component.

  24. #24
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So how would that work if I had for example a simple calculator APP?

    It is contrary to something a co-worker told me. He says they separate the data access layer with the model layer. Stating that, the model itself, is nothing except basically a data structure - it contains only get/set functions. They then have another layer called data access that pulls information from the database.

  25. #25
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The model can be structured in different ways. A common choice, is to make the data access a separate layer in the model. You can then add more logic-oriented objects on top of the access layer. I think, this is what you have had described, by your co-worker. Exactly how data access relates to business logic, varies. In an activerecord style, the business logic is usually implemented in a subclass of a data access component. So the relationship is resolved through inheritance. Another option is to use composition.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •