SitePoint Sponsor

User Tag List

Results 1 to 11 of 11
  1. #1
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Command Pattern MVC

    I have noticed a lot of examples in the forum are not using classes for every action rather than using methods.

    Instead of

    class product {
    function view();
    fuction insert();
    function update();
    }

    They are using

    class ProductInsert {
    function execute();
    }

    A lot of the frameworks use the first example when implementing MVC.

    My Questions:
    1. Which is the correct way?
    2. What are the advantages disadvantages?

  2. #2
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    368
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i use the first method, otherwise i would end up with hundreds of classes

  3. #3
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like having one controller for every resource, like Konstrukt handles it. One controller have a GET()-method and a POST()-method to handle get and post requests. And in the case of insert-/update-forms, you just let the update-controller inherit from the insert-controller, and use the same common functionality.

  4. #4
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've found the second method is better to use for implementing certain patterns like action filter and composite pattern.

  5. #5
    ✯✯✯ silver trophybronze trophy php_daemon's Avatar
    Join Date
    Mar 2006
    Posts
    5,284
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    The second method is more formalized, thus possible to implement with different design patterns, easier to maintain and reuse. Besides, using methods, such an object tends to easily grow into having too many responsibilitites.

  6. #6
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    I tend to have the one Controller with show (default), insert, et al in that Controller, and then have those responsibilities, etc in other separate classes which keeps the Controller in question a bit thin.

    But I see your point, as in a lot of examples that demonstrate the numerous frameworks out there, you do see the responsibilities, ie Models, Views etc are placed in the class method it's self.

    That is a bad practice in my opinion, as those responsibilities themselves should be encapsulated, and not exposed to the open. But that's life I suppose

    From my point of view, that's not to say that it's a bad design decision to retain multiple methods in the same Controller, if they are related, ie a QProducts_Controller for example?

  7. #7
    SitePoint Enthusiast
    Join Date
    Mar 2007
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I use the first example because my views arent built in the controller so most of my controllers look like $view->render()

    the second example is more re-usable and can co-operate better with other design patterns. But for now this is just too much work for me

  8. #8
    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)
    Between the two patterns, the latter is more decoupled, which means that it has a greater degree of reusability and is easier to replace. The cost is that it's slightly more complicated. This is a classical tradeoff, to be made in programming and so the proper choice depends on the context. FWIW, I prefer the latter approach.

  9. #9
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    368
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Between the two patterns, the latter is more decoupled, which means that it has a greater degree of reusability and is easier to replace. The cost is that it's slightly more complicated. This is a classical tradeoff, to be made in programming and so the proper choice depends on the context. FWIW, I prefer the latter approach.
    it wouldn't have to be complicated if php had proper OO features


    partial classes in C# solve a similar issue quite nicely

  10. #10
    SitePoint Zealot Mau's Avatar
    Join Date
    Jan 2006
    Location
    California, USA
    Posts
    134
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why not both? Symfony works with both.

  11. #11
    Beer drinker Srirangan's Avatar
    Join Date
    Jan 2005
    Location
    Beerland!
    Posts
    776
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blueyon View Post
    I have noticed a lot of examples in the forum are not using classes for every action rather than using methods.

    Instead of

    class product {
    function view();
    fuction insert();
    function update();
    }

    They are using

    class ProductInsert {
    function execute();
    }

    A lot of the frameworks use the first example when implementing MVC.

    My Questions:
    1. Which is the correct way?
    2. What are the advantages disadvantages?
    Don't make classes just for the heck of it. Build classes, but get your System Architecture right. Else you'd have just wasted time and money.
    Online Startups Insight for new entrepreneurs


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
  •