SitePoint Sponsor

User Tag List

Results 1 to 25 of 25
  1. #1
    SitePoint Enthusiast renan's Avatar
    Join Date
    Apr 2005
    Location
    Brazil
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    [Newbie] question in MVC.

    Duh.
    A simple example of MVC:
    I have a button (action, event), a model (an user), and a display table(html).
    When the user throw an event by clicking the button an C ontroller comes and execute the userView->getAllInfo(); method. This method do a select query and return an array(name, email, phone number, age, sex, ...) to the display table.

    Is it ok? I dont know...
    Plz give details for a newbie user!
    THANKS!!!

  2. #2
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, here is a simple summary of the MVC:

    A web page can possibly have 3 stages or more:
    1. A form is shown
    2. The form is submitted
    2.1. Action performed successfully
    2.2. Action not performed successfully

    If you add confirmation screens you get more stages.

    Now the responsiblity of the controller is to identify upon the Request in which stage the web page is. Therefore it performs a certain action on the model and it chooses the right view upon success or failure of the action performing.

    So the model is basically encapsulated from everything, does not know either about the views nor about the controller(s). The controller performs Actions and chooses the right views. The views can load the right html data or build a pdf page, whatever.

    Some people are of the opinion that whether the views or the controller performs the action does not matter. That's not true, because it's the controller's responsibility to choose the right view. Also, if you want to have multiple possible views for the same action (such as a html page and a pdf document) every view would carry out the domain logic/action performing, which would result in plenty of duplicate code.

    So in your case you would have two stages: The form is shown, and the form is submitted. Possibly you will have 3 stages if you differentiate between success and failure of the action performed.

    The controller selects some user row from the database upon an id field of the form (our Request). It then chooses a view, like a html page view, and passes that user either as an object (preferred!) or the raw data in variables. Then the view does the rest.

    Need code samples?

  3. #3
    SitePoint Enthusiast renan's Avatar
    Join Date
    Apr 2005
    Location
    Brazil
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hum ... Ok.
    The responsabilities:


    View
    To show. Can throw events for the controller. Example: a form to input data.

    Controller
    take the events and do actions. Example: I click in a button, throw an event(post data).

    Model
    My entities, like the db. Has methods.

    If I need to take/put data from a db, is the controller that has the sql query?
    I put the sql in the model . Recentley I read a lot of MVC articles, and they are all different. In my job people do weird codes. Im confused.

    $user->save();// you can use DAO here too.

    I need some code samples .
    Thanks.

  4. #4
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Before you go on to look at MVC you need to understand the standard presentation / domain / data access layering. This is a "satellite" view of an application ie you're looking down from a distance at the three main layers (or at least the three main layers in this scheme - there are others: HexagonalArchitecture). When you move in closer the layers are split up into many individual classes.

    The presentation layer receives user input and decides what response to make. It may manipulate the domain and creates a view. The presentation layer handles input and output: the UI in other words.

    With MVC, a clear boundary is drawn between controller and view inside the presentation layer. That's all there is to it - at least as far as layering is concerned. There could be a lot more to be said about exactly how to implement that, but the basic blueprint at least is simple.

    If you write nice, tight classes which do just one thing, MVC is going to happen almost by accident: controller roles (receiving input and making decisions) have nothing in common with view roles (gathering data and formatting it in a view).

  5. #5
    SitePoint Enthusiast renan's Avatar
    Join Date
    Apr 2005
    Location
    Brazil
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sure. Can someone say if Im right? Give code samples... Examples are always a better way to learn. I think I know what is MVC, I just dont know all this words , like dommain and views etc ...
    Try to mantain the focus in the mvc, I dont wanna know about other patterns. Not now.
    Again thanks.

  6. #6
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You might try looking over the two MVC articles linked in my signature.

    HTH
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  7. #7
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The domain is another term for the model. Domain objects contain business rules. They basically add value to raw data.

    Suppose you have records of customer orders. If customers get a free DVD once they've ordered x amount of goods that's a business rule. The added value is in calculating the total order value and deciding if this has reached the required amount.

    Or, suppose you have a file manager program which uses php to delete files created with the php uid (an ftp login uses a different uid and can't touch anything if it's not a group member). The raw directory listing is data. The added value would be a domain object which flags entries created with the php uid with boolean true. Simply returning the uid would be data access: the domain logic in this context is in identifying files with the php uid so that later you can add a delete link for each in the view.

    A view gathers data from domain objects (or direct from the data access layer if there's no domain logic to be done) and, with html output, makes this available to an html template which defines the page layout and adds all the formatting.

    With the filemanager example, presentation logic in the template would look for the boolean flags mentioned earlier and, if found, would add a delete link. Note the subtle difference between domain logic and presentation logic. The domain object doesn't know anything about the UI: it just identifies php-owned items. The presentation logic decides what should be done with them.

    Sometimes these rules are bent but be careful. Separating the domain from the presentation layer is important.

  8. #8
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    McGruff...I see you think the view should gather data. Please read my previous post..shouldn't the controller gather the data and pass it to the View which formats it?

  9. #9
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DarkAngelBGE
    Now the responsiblity of the controller is to identify upon the Request in which stage the web page is. Therefore it performs a certain action on the model and it chooses the right view upon success or failure of the action performing.
    Aah, something just clicked. Do you view "actions" themselves as part of the model?

    If so, that explains why some people insist on putting each action in its own class - because a controller should just call an action, not perform it. For me, actions have been in charge of getting the models to perform (C-M distinction), so I've always seen them as part of the controller.

    Quote Originally Posted by DarkAngelBGE
    McGruff...I see you think the view should gather data. Please read my previous post..shouldn't the controller gather the data and pass it to the View which formats it?
    That's how I see it - actions gather data, which are themselves part of the controller. (The actions act as Mediators for the models.)

    Cheers,
    Douglas
    Hello World

  10. #10
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by renan
    Try to mantain the focus in the mvc, I dont wanna know about other patterns.
    MVC is quite a high level pattern, it talks about how the whole application should work. Many other patterns describe how small groups of classes work together, or even how to design a single class. I use the mediator pattern to implement MVC for example
    Hello World

  11. #11
    SitePoint Enthusiast renan's Avatar
    Join Date
    Apr 2005
    Location
    Brazil
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Holy sh**
    Im on the right way, cause I discovered that I wrote +- MVC applications...
    Going to study MVC now ... Bye and thanks to all

  12. #12
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes as Douglas said, MVC is a high level pattern, defining the core architecture of an application. There are plenty of other patterns that come with it..such as Decorators for the FrontController to pick the right Command or Controller. MVC is complex.

    Thanks for your thoughts regarding that responsibility issue, Douglas.

  13. #13
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DarkAngelBGE
    shouldn't the controller gather the data and pass it to the View which formats it?
    To my mind, that would be breaking the controller/view separation which is the whole point of MVC. Gathering data for a view seems to me to be a responsibility of the view - the controller just fires the starter's gun.

  14. #14
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    the whole point of MVC ... the controller just fires the starter's gun.
    Take this image:


    For me, the breakdown is: M = red+pink, V = green and C = blue.

    McGruff, in your interpretation if MVC, would the "Action Controller" be part of the View? (Assuming you consider this setup to be MVC in the first place.)

    It seems that when you talk about a controller which "just fires the starter's gun", you mean only the dispatcher in the diagram above.

    Douglas
    Hello World

  15. #15
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But McGruff, if you want to have several presentations (i.e. Views) of the same data, each View would have to gather that data for itself again. That would mean the whole data gathering process would be in every view. Shouldn't this be considered duplicated code?

  16. #16
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    would the "Action Controller" be part of the View?
    There are two "actions" in the response: create all the gubbins for a browser page (headers & content) and send an email (which itself is a kind of view).

    I think the controller should simply announce: "right I want a Foo view and an email". The Foo view itself should know everything about how to produce that view. It manages itself after getting a message from the controller - same with the email. Encapsulation means telling objects to do things rather than micro-managing them.

    The controller is an administrator. It doesn't actually do anything just tells other people to do things. I think the "ActionController" term is slightly misleading.

  17. #17
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DarkAngelBGE
    if you want to have several presentations (i.e. Views) of the same data, each View would have to gather that data for itself again.
    I'd encapsulate the data-gathering in a FooViewData object and use different output strategies ie a FooViewHtmlPrinter, FooViewCommandLinePrinter and so on.

  18. #18
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    I'd encapsulate the data-gathering in a FooViewData object
    I was about to make a longer reply to the post just before the one above, but this hits it on the head. Your "FooViewData" is my "ActionController".

    I feel that you've taken the idea of a controller and replaced it with just one component of a controller, the dispatcher. From there, you've got to reinvent the controller behaviour for each view. If you rely fully on a view gathering its own data, you inhibit it from reacting to that data: you end up with views rendering views. Relying on MV layers + a dispatcher is just going to complicate the view (giving you FooView + FooViewData + FooViewPrinter) which could easily be solved using MVC with a controller which actually does some controlling.

    Douglas
    Last edited by DougBTX; Apr 23, 2005 at 12:45.
    Hello World

  19. #19
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hey doug, what did you use to create that flowchart? looks nice, my visio skills are sucking lately. lol
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  20. #20
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jplush76
    hey doug, what did you use to create that flowchart? looks nice, my visio skills are sucking lately. lol
    I didn't make it, it is just linked off this site. I mean, the whole DRY thing, if someone else has made a nice graphic, why not reuse it? And if they've also made a framework to back the nice graphic up...

    Douglas
    Hello World

  21. #21
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Relying on MV layers + a dispatcher is just going to complicate the view (giving you FooView + FooViewData + FooViewPrinter) which could easily be solved using MVC with a controller which actually does some controlling.
    This is a great point. In fact MVC does not imply 1 Model, 1 View, 1 Controller. It's really about the separations between those parts. The classic Struts style MVC has (at least) two controllers: a Front Controller and an Application Controller. This is similar to the Dispatcher and Action Controller combo in the graphic you posted.
    Christopher

  22. #22
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    I feel that you've taken the idea of a controller and replaced it with just one component of a controller, the dispatcher....etc
    Douglas
    Sorry, not sure what you mean. I don't know Rails which probably doesn't help.

  23. #23
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Mcgruff, you convinced me about this.

  24. #24
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    ...
    ..a controller which actually does some controlling.
    Is PresentationModel the kind of 'controlling' you're talking about? I'd say the C in MVC is an input controller which makes decisions about what kind of response to make ie which view to call as well as any other actions which need to be done. Presentation model decisions are about what to put in the view eg a "moderate this forum" link if the user is authenticated and authorised.

  25. #25
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Is PresentationModel the kind of 'controlling' you're talking about?
    More of arborint's Application Controller.

    *

    The diagram has a "get domain command" which is then then "run". In the Rails case, the "get" is implicit in the "run domain command" because it is represented by a method instead of an object. Considering how simple they are (1-10 lines, average for basecamp is 5) methods seem the better choise.

    *labels:
    Input Controller = "Dispatcher"
    Application Controller = "Action Controller"
    Domain command = "Action"
    View = "View"

    Douglas
    Hello World


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
  •