SitePoint Sponsor

User Tag List

Page 3 of 5 FirstFirst 12345 LastLast
Results 51 to 75 of 104
  1. #51
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by pakmannen View Post
    I'm also trying to create a template based solution. At the moment my "flow" sort of looks like this: FrontController -> "Command" -> View -> Template

    It feels like one of them is redundant. Should I really have to create three files (command, view, template) for each "new" page? I'm curious how you solved this. Is it possible to integrate the "Commands" into the FrontController or something?
    FrontController and Commands(which are also called Controllers in MVC parlance) are different concepts. I would not try integrating them.

    Most of my pages do end up with three classes, each in their own file. But keep in mind that you may end up with a controller driving multiple views or possibly multiple controllers using the same views. Views themselves often end up being composites which means they get broken up into smaller classes which in turn will get shared between multiple views. And some controllers will not have any views, they just redirect.

  2. #52
    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 McGruff View Post
    The model is another name for the domain layer not the data access layer.
    I've always considered both the domain- and data layers to be part of the model. Where the domain layer handles the 'logic' and the data layer handles the IO (database, file or other). However, an ActiveRecord type of solution combines both layers while a more classic approach separates the two.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  3. #53
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    122
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    If you announce that you're going to have a separate view and controller - MVC - and then don't bother to keep them apart you might as well claim to be a vegetarian and then insist that vegetarians are free to implement vegetarianism with as many degrees of meat-eating as they like.
    Again, you're coming up with silly analogies that make no sense. Vegetarianism is defined as a strict, 100% no meat lifestyle. MVC is a design pattern that was never classed a a strict 100% no mixing of view and controller. No design pattern is defined in a strict must-follow recipe. The degree of separation depends entirely on the context.

  4. #54
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    The model is another name for the domain layer not the data access layer.
    McGruff, is your sole purpose in life to argue and make nonsensical comments? The model layer is where all the data access happens (communication with databases, flat file storage, etc.), so YES it IS the data access layer.

    Martin Fowler's eaaCatalog has two separate categories called "Domain Logic Patterns" and "Data Source Architectural Patterns". Guess which one has ActiveRecord, TableDataGateway, RowDataGateway, and Data Mapper - the patterns typically found in the MVC "Model" layer?

    The catalog even describes the ActiveRecord pattern as "An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data."

    Encapsulating database access is the primary function - data access. Don't make arguments where there is no purpose. You knew as well as everyone else does what I mean when I say the "data access" layer.

  5. #55
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    122
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Lastcraft put it best with (and I paraphrase) - "the model in MVC is everything else that the controllers and views aren't".

    So it's the data access layer and the domain layer. Though I guess you could argue that in a well designed application the controllers and view should only interact with the domain layer. Again, the level of layer interaction strictness is dependent on the problem.

  6. #56
    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 Czaries View Post
    McGruff, is your sole purpose in life to argue and make nonsensical comments?
    Usually my purpose is to steer clear of MVC topics. It causes endless confusion but it's impossible to do anything about that. It's the tenth circle of hell.

    TableDataGateway, RowDataGateway, and Data Mapper are data access patterns. They just fetch and carry raw data but don't have any domain logic.

    ActiveRecord isn't the same thing at all: this is a domain object. Although it does also know how to persist its data the interesting bit is the domain logic. Fetching and carrying isn't interesting; nothing is really happening - just data shuffling backwards and forwards across an application boundary. This and domain logic are two very different things. It doesn't help that people often describe RowDataGateways as ActiveRecords.

    I suppose you could think of the model as encompassing domain and data access but I think that's a bit confusing. Domain layer and data access layer are better terms and you'll virtually always find this distinction being made in a well-designed app. I'd never talk about models at all unless someone else raised the term.

    Really what MVC is all about is introducing the idea of presentation, domain and data access to programmers taking their first steps in OOP. MVC is the buzz word that everyone latches onto but you can't understand MVC without first understanding presentation, domain and data access. I'd leave the view controller split until later because it's a little harder to understand the significance of that. Hardly anyone ever gets it in any of the articles you can find.

  7. #57
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have read about the difference between the Page Controller and Front Controller patterns. These were especially helpful:
    - Page Controller
    - Front Controller

    I've decided to wait with the Front Controller and focus on the Page Controller pattern for now, since it's one less layer of complexity. What I'm wondering is, do you implement your Page Controllers as classes based on a BaseController (like the Microsoft examples) or as procedural code? The advantage of having a BaseController is obviously that you can put some common stuff there.

    But if a Page Controller is a Class, and at the same time the entry point of the application, where do you instantiate it? After the class declaration?
    PHP Code:
    #include necessary file
    class PageController extends BaseController
    {
        public function 
    execute();
    }
    $controller = new PageController();
    $controller->execute(); 

  8. #58
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Hi pakmannen,
    Yes, you need to declare the controller class then instantiate it. And of course if you are leaning towards an OOP approach then minimizing code outside of classes is a good thing.

    I read your links and they do provide a good summary. I'm not entirely sure that I agree with the notion that a Front Controller is significantly more complicated than a Page Controller. But to each their own.

  9. #59
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the reply ahundiak. I wouldn't say Front Controllers are significantly more complicated, but they do seem redundant in many cases. Correct me if I'm wrong, but a Front Controller merely forwards to a Command, which is practically the same thing as a Page Controller. In many cases it feels like the Front Controller is doing what the Web server itself should do: serve pages. I'm sure the Front Controller is good for complex websites, but if you don't have a need for it, Page Controllers seem more sensible. But what do I know eh?

  10. #60
    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 shea View Post
    The degree of separation depends entirely on the context.
    We have to have clearly defined ideas so that we can communicate and so that we can analyse common problems effectively.

    The reason to separate views and controllers is to isolate change. MVC allows you to change the view without also changing a controller. There aren't really any shades of grey: you either have to change controller code when you change a view or you don't. That prohibits controllers passing data - variables or "model" objects - to views since clearly you'll have to change the controller when the data displayed in a view changes.

    That's not to say this is bad design. In a sense it's not design at all: the controller happens to have some domain objects lying around so they get chucked at the view simply because it's convenient rather than through any conscious choice. Still, if your controllers and views don't need to vary independently it doesn't doesn't matter if they are merged in a single presentation layer (just don't call that MVC).

    If we use a refactoring app as an example, the domain action is to hunt through a filesystem, editing files. A controller will send messages to various domain objects to achieve this, but what about a view? There are all kinds of possibilities, eg:

    (1) one-liner: "operation succeeded/failed"
    (2) list every file which was edited
    (3) print diffs for every file which was edited
    (4) display the results of an "all tests" run using an app like SimpleTest

    In each case the domain action is exactly the same. If data were passed in to the view from a controller the controller has to be changed when the view details change. Separating controller and view would be useful if you want to support several view types. Maybe you're exploring a new domain and can't decide yet.

  11. #61
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Hi pakmannen,

    The value of a front controller lies in the fact that it isolates your commands from the actual web server. You can make yourself a nice HTTPRequest and HTTPResponse objects, let the front controller init them and then your commands need never worry about $_GET or $_POST again. Especially nice if you buy into the notion of unit testing.

    The other thing with using a front controller is that you only need one simple php file in the actual web directory. Correct me if I am wrong but with the basic Page Controller implementation, each page controller file need to be in the public web directory. To me at least this seems to make deployment and maintenance more difficult.

    So I guess I would argue that even for a simple website, a front controller is easier. It doesn't have to be fancy. You could use an url like:

    whatever?controller=ControllerClassname&action=ActionMethodName

    The your front controller just does:
    PHP Code:
    $command = new $controller($request,$response);
    $command->$action(); 
    I'm really not seeing where the redundancy is coming in.

  12. #62
    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 pakmannen View Post
    where do you instantiate it? After the class declaration?
    I'd keep classes in separate files from runner code. You'll get in a mess if you don't. Also, this allows you to store a code library outside of the web root which is better from a security point of view.

    A FrontController provides a common way of processing requests. Inheriting from a shared PageController class does much the same thing.

  13. #63
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    I'd keep classes in separate files from runner code. You'll get in a mess if you don't. Also, this allows you to store a code library outside of the web root which is better from a security point of view.
    How would you do that with a Page Controller pattern? (IE, no Front Controller) I do not see how you could make your PageControllers classes AND entry points without instantiating them after you declare them. Could you provide a quick example perhaps?

    @ahundiak: It is correct that you place all your PageControllers in the public folder. I found this to be an interesting article regarding PageController VS FrontController: http://www.phppatterns.com/docs/desi...roller_and_php

  14. #64
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    That prohibits controllers passing data - variables or "model" objects - to views since clearly you'll have to change the controller when the data displayed in a view changes.
    What about GET information such as $id, $page, $limit etc? A View would need this information when it calls the Model to get the things it wants. Wouldn't the controller need to pass this on to the View? Or should the View access this directly from the $_GET?
    Still, if your controllers and views don't need to vary independently it doesn't doesn't matter if they are merged in a single presentation layer (just don't call that MVC).
    I read somewhere that this is called the Document-View pattern, where Document is the data and View is input/output. I guess you need to separate the View and Controller if you want more than one Controller to serve the same View (and avoid code duplication). AddItemController and RemoveItemController both serve the ListItemsView for instance. If you would combine the Controller and View (in a Document-View pattern) you would have the same code (Fetching the Model state) in both files.

  15. #65
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by pakmannen View Post
    @ahundiak: It is correct that you place all your PageControllers in the public folder. I found this to be an interesting article regarding PageController VS FrontController: http://www.phppatterns.com/docs/desi...roller_and_php
    Over the years I have read many articles from phppatterns.com and have learned a great deal from them. But I don't think this is one of their better efforts.

    The article starts with a simple front controller example:
    PHP Code:
    <?php
    // index.php

    switch ( @$_GET['action'] ) {
        case 
    'edit':
            include (
    'actions/edit.php');
        break;
        case 
    'post':
            include (
    'actions/post.php');
        break;
        case 
    'delete':
            include (
    'actions/delete.php');
        break;
        case 
    'default':
            include (
    'actions/view.php');
        break;
    }
    ?>
    And then comments:
    PHP re-creates it environment on every request.

    In the simple example above, that may not seem like a problem, but what about when you have hundreds of Page Controllers? You end up with a massive switch statement or perhaps something disguised in an array, an XML document or whatever. For every page request, PHP will have to reload a bunch of data which is irrelevant to the current request the user is trying to perform.
    This is simply a strawman argument. Of course you don't want a huge config file or massive switch statement. Which is why people doing big sites break things up into modules. And if you look at the example I gave in which the command class name is derived from a request argument then the need for even a switch statement goes away. In any event, notice that the author is arguing that for simple sites front controller works well, it's only when you develop complex sites that difficulties might ensue. Just the opposite of what you were offering as the reason for choosing Page Controller over Front controller.

    The article then goes on to saying:
    The other problem with running everything through a single PHP script, such as index.php, is it imposes a significant restriction on the flexibility PHP offers, by default, of allowing developers to “drop a script” anywhere under the web server’s web root directory. Adopting this approach will likely cause you problems later, both from the practical perspective of having to updating the command hierarchy each time you create a new file to issues like integration with other PHP applicatoins.
    For lack of a better word, this is just plain nonsense. Even with a front controller you can still drop scripts pretty much anywhere you want. And if you are trying to integrate another application (which, IMHO, falls under the header of complexity) what would rather have? One file to mess around with or several hundred files that need to be moved to the web root directory?

    The article also has:
    But the word serve should set off alarm bells. PHP is not a web server itself (ignoring the odd exception) but used as an add-on to an existing web server, such as Apache. It’s Apache that does the serving, not PHP.
    Which again is a bit of a stretch. It is up to PHP to decide how to process a given request. Deciding which command to use for a given request is a trivial part of the entire process.

    What seems a bit funny is that as you read through the result of the article, the author almost seems to convince himself that maybe front controllers are not such a bad idea after all.

  16. #66
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Whats a Model for?

    As always, Martin Fowler has the last word,

    http://martinfowler.com/distributedC...ng/purpose.pdf

    As for McGruff, well... That is just one person you learn to loathe, surely? I have my thoughts but this is a public forum, so enough said.

  17. #67
    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 Dr Livingston View Post
    I have my thoughts
    They must be very lonely.

  18. #68
    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 pakmannen View Post
    I do not see how you could make your PageControllers classes AND entry points without instantiating them after you declare them. Could you provide a quick example perhaps?
    PHP Code:
    require_once('path/to/the-file-with-PageController.php');
    $controller = new PageController();
    $controller->execute(); 
    Quote Originally Posted by pakmannen View Post
    What about GET information such as $id, $page, $limit etc? A View would need this information when it calls the Model to get the things it wants. Wouldn't the controller need to pass this on to the View? Or should the View access this directly from the $_GET?
    The kind of separation I've been talking about requires another part of the system: an assembly layer. Some kind of dumb assembler object would wire everything up together. It's "dumb" because that's about all it does; there's very little logic in here. You might receive input in some kind of request object then controller and view both get a reference to it. Same with domain objects (or "models", if you like) with the proviso that the view is always read-only. Only the controller is allowed to manipulate domain objects.

  19. #69
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    122
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    We have to have clearly defined ideas so that we can communicate and so that we can analyse common problems effectively.
    We do have clearly defined ideas. I have no problem understanding the more strict solution you have defined nor do I have a problem understanding the more blurred approach others have defined. I have successfully used both methods depending on how complex the application is. This is basic stuff - I don't see how you can get quite so worked up about it.

  20. #70
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Er.. worked up? What are you talking about? I thought we were having a discussion where I was politely ignoring you calling me "silly"...

  21. #71
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    122
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "Again, you're coming up with silly analogies that make no sense."
    Mate, that is in no way calling you silly.

  22. #72
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's OK really. If you think something is bad I'd much rather you said so. In fact I need you to say so. That's the starting point for discussion even if in the end we don't agree.

  23. #73
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ahundiak View Post
    You can make yourself a nice HTTPRequest and HTTPResponse objects, let the front controller init them and then your commands need never worry about $_GET or $_POST again. Especially nice if you buy into the notion of unit testing.
    This sounds interesting, where can I read about that? Tried to google and search sitepoint but no luck.

    The your front controller just does:
    PHP Code:
    $command = new $controller($request,$response);
    $command->$action(); 
    I've wondered about this. The "action" is a method of the command correct? What kind of method would that be? I thought you'd mostly have an Execute() method which you call manually where everything takes place.

    I'm really not seeing where the redundancy is coming in.
    Do you not agree that Commands and PageControllers are extremely similar? A FrontController seems to be something that binds PageControllers together, and so far, without talking about filters or request objects, which I know nothing about, I don't see the point. I'm sure I will eventually.

    Quote Originally Posted by McGruff View Post
    PHP Code:
    require_once('path/to/the-file-with-PageController.php');
    $controller = new PageController();
    $controller->execute(); 
    You wouldn't want to have 50 controllers tucked in a folder and then 50 files like that calling them. Then you'd automate the process into one file and voila: a FrontController. Right?

    Back to Controller/View separation. If you're using a Template as well, does this look alright:
    PHP Code:
    class MyController
    {
        function 
    __construct()
        {
            
    $this->model = new MyModel();
            if (
    $this->model->UpdateModel())
                
    $this->view = new MyView();
            else
                
    $this->view = new MyOtherView();
        }
    }

    class 
    MyView
    {
        function 
    __construct()
        {
            
    $this->model = new MyModel();
            
    $this->tpl = new Template('MyTemplate');
            
    $this->tpl->array $this->model->GetArray();
            
    $this->tpl->Render();
        }


  24. #74
    SitePoint Enthusiast
    Join Date
    Aug 2007
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When using a Front Controller, do you really need a Command for every View? Could you not do something like this:

    index.php?view=myview
    index.php?command=mycommand

    For static pages, where the Model is never updated (and hence, a Command would do nothing but choose a View) could you not leave the View selection up to the Front Controller? And when you DO need to update the Model, the Front Controller invokes a Command which selects the View.
    Last edited by pakmannen; Aug 31, 2007 at 05:23.

  25. #75
    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 pakmannen View Post
    Do you not agree that Commands and PageControllers are extremely similar? A FrontController seems to be something that binds PageControllers together, and so far, without talking about filters or request objects, which I know nothing about, I don't see the point. I'm sure I will eventually.
    Almost: Page/FrontController are input controllers ie they receive input, decide what to do about it, then pull levers and press buttons to make it happen. A FrontController might hand over to something quite similar to a PageController except that it doesn't receive input.

    Quote Originally Posted by pakmannen View Post
    You wouldn't want to have 50 controllers tucked in a folder and then 50 files like that calling them. Then you'd automate the process into one file and voila: a FrontController. Right?
    If you like. Either is OK.

    Quote Originally Posted by pakmannen View Post
    Back to Controller/View separation. If you're using a Template as well, does this look alright:
    How about:
    PHP Code:
    class FooAssembler {

        function 
    getController() {
            return new 
    MyController(
                
    $this->_getModel(), 
                
    $this);
        }
        
    // use if( !isset) when want a single instance
        
    function _getModel() {
            if( !isset(
    $this->model)) {
                
    $this->model = new MyModel();
            }
            return 
    $this->model;
        }
        function 
    getUpdaterView() {
            return ...;
        }
        function 
    getOtherView() {
            return ...;
        }
        function 
    _getTemplate() {
            return ...;
        }
    }
    class 
    MyController {
        function 
    __construct($model$assembler) {
            
    $this->_model $model;
            if (....)
                
    $this->_view $assembler->getUpdaterView();
            else
                
    $this->_view $assembler->getOtherView();
        }
        function 
    execute() {
            
    $this->_model->pressButton();
            
    $this->_model->pullLever();
            
    $this->_view->render();
        }
    }
    class 
    MyView {
        function 
    __construct($model$template) {
            ...
            ...
        }
        function 
    render() {
            ...
            ...
        }

    A factory object can take over object instantiation, injecting all the dependencies. This is what I'd call a dumb assembler with little or no logic of its own apart from how to wire everything up. For example, in the above code the controller decides which view it wants and then asks the assembler for it.

    This is a powerful technique which leads to very flexible designs. Since the classes now depend on an interface rather than a specific class, you can easily change the behaviour of the system simply by passing different objects in.

    This also helps make make code easier to (unit) test. In a test, mock objects can be passed in.

    With OOP, we spend all our time fencing code off into discrete components but this creates a problem: how do we get everything talking to each other? Anything in the assembler scope can be introduced to anything else so most of your how-to-get-from-A-to-B-problems just disappeared.


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
  •