SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 68 of 68

Thread: MVC vs PAC

  1. #51
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Withe respect to configuring via the constructor:
    PHP Code:
        public function __construct($manager$formType$redirect$template) {
            
    $this->manager $manager;
            
    $this->formType $formType;
            
    $this->redirect $redirect;
            
    $this->template $template
    I fully understand the flexibility that such an approach offers. And in fact I use this in the cases where I need to.

    The biggest objection I have to always doing this is that it means I basically need ControllerAction classes instead of Controller classes. That's because I'll typically have multiple actions (edit,create,show,list etc) inside of one Controller class. To make the class configurable means adding a bunch more arguments to the constructor (different set for each method) which in turn makes the class very fragile.

    I have gone down the ControllerAction class before (and on occasion still use it when needed) but all it seems to do for me is to multiply the number of classes without providing much practical benefit.

    I'm not a big fan of adding support for flexibility when I don't need it. Looking over my code for the last 12 years or so reveals very few cases where I have to copy/paste code just to make a slight tweak. I simply don't need to change the template or change the form or change the manager.

  2. #52
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I said "I'd handle" because I wanted to keep things as pure MVC as possible. My production code deals with slightly more complex scenarios which are far beyond the scope of the very broad definition of MVC. I abstract things a lot further to to add flexibility, but trying to introduce that abstraction while explaining the fundamental concepts of MVC would have muddied the waters and given a very difficult to understand example of what is MVC (Which has 3 distinctive components) and what is a real world system where we have a lot more complexity and the need for further abstraction.


    As an example, I have a TemplatedView class that looks like this:


    PHP Code:
    <?php 
    class TemplatedView implements View {    
        private 
    $plugins = array();

        public function 
    __construct(ViewTemplate $templateHookFactory $hf) {
            
    $this->template $template;
            
    $this->hook $hf;
        }
        
        public function 
    addHook($nameHook $hook) {
            
    $this->template->addHook($name$hook);
        }
        

        public function 
    assign($key$value null) {
            if (
    $value == null && is_array($key)) {
                foreach (
    $key as $k => $v$this->assign($k$v);
            }
            else {
                
    $hook $this->hook->objectSet($key$value);
                
    $hook->template $this->template;
                if (
    is_array($value) || $value instanceof DataSet$this->template->addHook($key$hook);
                else if (
    is_object($value)) $this->template->addHook($key$this->hook->object($value));            
                else 
    $this->template->replace($key$value);
            }
            return 
    $this;
        }
        
        public function 
    output() {
            foreach (
    $this->plugins as $plugin$plugin->visit($this);
            
            
    $output $this->template->output();
            foreach (
    $this->plugins as $plugin) {
                
                if (
    $plugin instanceof ViewPluginOutput) {
                    
    $output $plugin->output($output);
                }
            }
            return 
    $output;
        }
        
        public function 
    addPlugin(ViewPlugin $viewPlugin) {
            
    $this->plugins[] = $viewPlugin;        
        }
    }
    ?>



    What I had described as a "FormView" in my example above, would actually be expressed as a ViewPlugin. I don't want to get into too much detail here but a ViewPlugin encapsulates the model and the view employs the visitor pattern to enable the view logic to be further separated.

    What this means on a practical level is that the View logic which encapsulates the template isn't coupled to the model. This allows any View Type (Which may use a different template system or different output mechanism, PDF, csv export, etc) as well as essentially allowing multiple inheritance. Views could have both a form and Pagination, for instance by adding two plugins.

    Here's my FormViewPlugin class:

    PHP Code:
    <?php 
    class FormViewPlugin implements ViewPluginOutput {
        protected 
    $hookFactory;
        protected 
    $viewModel;
        protected 
    $form;
        
        public function 
    __construct(FormViewModel $viewModelHookFactory $hookFactory) {
            
    $this->viewModel $viewModel;
            
    $this->hookFactory $hookFactory;
        }
        
        
        protected function 
    getForm() {
            if (!
    $this->form)  $this->form $this->viewModel->getForm();
            return 
    $this->form;
        }
        
        
        protected function 
    run() {
            
        }
        
        private function 
    getMode() {
            return 
    is_callable(array($this->viewModel'getMode')) ? $this->viewModel->getMode() : FormViewModel::EDIT;
        }
        
        protected function 
    isValid() {
            return 
    is_callable(array($this->viewModel'isValid')) ? $this->viewModel->isValid($this->getForm()) : $this->form->isValid();
        }
        
        protected function 
    getErrors() {
            return 
    is_callable(array($this->viewModel'getErrors')) ? $this->viewModel->getErrors() + $this->form->getErrors(): $this->form->getErrors();
        }
        
        public function 
    visit(View $view) { 
            
    $view->assign('model'$this->viewModel);
            
    $this->getForm();
            
            
    $hook $this->hookFactory->form($this->formFormViewModel::DISPLAY $this->getMode());
        
            
    $view->addHook($this->form->name$hook);
            

            
            
    $errors $this->getErrors();
            if (!
    $this->form->isValid() || count($errors) > 0) {
                
    $view->assign('error'true);
                
    $view->assign('errors'$this->getErrors());
            }
            else 
    $view->assign('error'false);
            
        }
        
        public function 
    output($output) {
            
    $mode $this->getMode();
            if (
    FormViewModel::EDIT $mode && $this->form->isSubmitted() && $this->isValid()) {
                
    $submitted $this->viewModel->getSubmittedView();
                if (!(
    $submitted instanceof View)) throw new Exception('ViewModel ' get_class($this->viewModel) . '::getSubmittedView must return instance of View');
                if (
    FormViewModel::APPEND_SUBMITTED $mode) return $output $submitted->output();
                else if (
    FormViewModel::PREPEND_SUBMITTED $mode) return $submitted->output() . $output;
                else return 
    $submitted->output();
            }
            else return 
    $output;
        }
    }
    ?>

    What this means is that the form logic isn't tightly coupled to my template logic; the result is that the form logic can be used with any template system by adding the plugin to a different class that implements view:

    PHP Code:
    interface View {
        public function 
    assign($key$value null);
        public function 
    addPlugin(ViewPlugin $plugin);
        public function 
    output();

    Once again, this is waaaay beyond the scope of MVC itself and in the previous post I was trying to highlight the advantages of MVC over PAC without getting too much into the topic of Separation of Concerns within the individual components. One step at a time, eh? Unfortunately where I work our codebase is huge. Due to a mix of bad management and changes in technology we've had many developers over the years who've used different template systems. Being able to unify those as much as possible makes everyone's job easier. Admittedly, it would be better to convert all the templates into one system but that is an arduous task that will require too many hours that could be spent on real work.


    I fully understand the flexibility that such an approach offers. And in fact I use this in the cases where I need to.

    The biggest objection I have to always doing this is that it means I basically need ControllerAction classes instead of Controller classes. That's because I'll typically have multiple actions (edit,create,show,list etc) inside of one Controller class. To make the class configurable means adding a bunch more arguments to the constructor (different set for each method) which in turn makes the class very fragile.
    But that's entirely down to a conscious decision higher up the application to break the Single Responsibility Principle. Of course it becomes messy when you do this. You should group controller actions for a view. A controller for a list of products may have the actions "Sort", "Search" and "Delete". Editing a product requires a different view, and therefore a different controller. At the simplest level it means you don't need repeat $this->render('foo.tpl.php'); in every single controller action. Surely this alone makes it a worthwhile exercise?

    I'm not a big fan of adding support for flexibility when I don't need it. Looking over my code for the last 12 years or so reveals very few cases where I have to copy/paste code just to make a slight tweak. I simply don't need to change the template or change the form or change the manager.
    As I've said before, most programmers I know are not clairvoyant. It's impossible to know how the requirements will change in the future. Building flexible software avoids "Sorry the system isn't able to cope with that" or you as a developer scratching your head thinking how best to cludge the system in order to achieve it.

    Here's a couple of request from clients I never would have anticipated during the initial development:

    "There are now two types of holiday bookings. One of them shows prices, and forces customer to select a date from a list of available dates. The other doesn't show any prices and allows customers to enter any date as their start date"

    Without a flexibile system this would have been a nightmare. I had to have two concurrent sets of: templates, forms, validation while keeping the entire booking process (which was very long! Selecting a holiday, all the supplements, party details etc) consistent.


    "We want to use our internal stock-system's product database rather than uploading products to both the website and our internal system. The internal system provides a web service"

    They still wanted to manage ordes on the website, so the Mysql database was still needed. If the system wasn't flexible this would have been impossible. Because all the queries were abstracted away inside an ORM and the ORM supported multiple data-sources this was just a matter of re-writing the DataMapper implementation for the Products model and all the other existing code just worked without any hacky workarounds.. No messing about converting data, or exporting/importing to mysql.

    Flexibility is very important. You never know how things will change in the future. It takes little upfront effort to introduce flexibility at the beginning of a project. Trying to introduce flexibility afterwards is a very painful and time consuming exercise.

  3. #53
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    So I have at least two answers to the question of why PAC should be used instead of "pure MVC". I'll post one at a time.

    Answer 1: Many existing publicly available frameworks use PAC. As far as I can tell, there are none for "pure MVC".

    This of course is basically an argument from authority but in this case it's reasonable. Having access to existing frameworks such as Symfony 2 or CodeIgniter means that you can actually build applications and see how thing fit together. Plus you have plenty of examples and plenty of sources for help.

    In the case of "pure MVC" all we seem to have are snippets of code describing how things might work together as opposed to how they actually do. Very difficult to compare bananas to monkeys. I for one don't see the huge advantage of having view classes. If I had something I could actually use along with some working examples then the light might dawn.

    It's also difficult to figure out what the actual differences between PAC and "pure MVC". For example, in this thread, it would appear the "pure MVC" requires dependencies to be injected. In the case of Symfony2 PAC it's optional. Is this an actual difference between the two methods or is it a question of style? Hard to tell without seeing an actual framework in action.

    The bottom line is that no one has yet taken the time to put together a "pure MVC" framework and released it to the public. You would think that if it really did offer significant advantages then someone would have done so by now. I think there are plenty of low level programmers such as myself who enjoy taking new stuff out for test drives. And being fundamentally lazy means that I can usually identify stuff that makes my life easier.

    In a way it's similar to dependency injection. Over the years I read a number of articles on it and downloaded various snippets and classes. I understood the advantage if using DI but I could never really see how all the pieces fit together. Then along came Symfony 2 with it's dependency injection component and examples and the light suddenly turned on.

  4. #54
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I think you're right. And I agree that it's unfortunate there are no major frameworks which use MVC. But you hit the nail on the head: My main issue with this whole scenario is that everyone claims to be using MVC when they're not and don't even know what MVC is.

    What makes this scenario worse is that googling "MVC in PHP" brings up a whole host of information on PAC. Nowhere does it mention anywhere that they're not using MVC. People simply do not know the difference and never will because they think they're using MVC.

    How do you know you made the right choice when you never even made a choice? My issue here is that people don't even consider alternatives. People being developers or framework authors and as far as I can tell it's because they don't know of any alternatives.

    That said, it's still not an argument for the fundamental question of PAC vs MVC. PAC is more widespread, but it doesn't mean it's the best tool for the job. Justin Beiber is more popular than Mozart, it doesn't follow that Justin Beiber is technically superior.

    I can't argue against "But there's not enough examples". I've been trying to do my part on that front but quite frankly, it's well beyond the scope my own very limited influence can have. At least if I can get people thinking about what they're doing rather than defaulting to "I'll use (what I consider) MVC" I might get the ball rolling.

    Similar to your experience with Dependency Injection, I only really found the benefits of MVC after I started using it. I never liked the way PAC works because everything is centralised around a single router/controller as an entry point (With MVC, for instance, I don't have a centralised entry point so anything can be an entry point. My own framework allows views to do this: $this->include('/userdetails/123'); which (as a simplistic example) would pull into a view exactly what you'd see within the site layout if you visited site.com/userdetails/123 which allows everything to be entirely component based and therefore reusable. PAC makes this difficult because the entry point isn't easily accessible or reusable and does too much. That was my first goal when I was exploring MVC, the more I used it the more benefits I discovered.

    You would think that if it really did offer significant advantages then someone would have done so by now.
    This is where we disagree. How long did it take DI to become mainstream? A very long time after people first started writing about it ( http://martinfowler.com/articles/injection.html - early 2004 ). I've yet to see any framework documentation or mission statement that says why it uses the architecture it does or, more to the point, why it didn't choose others and what others it considered. I'm 100% certain that in every case no real choice was actually made through an informed decision making process. CodeIgnitor's documentation, for instance says "This is how MVC works" with no caveats, no mentions of variations, nothing.

  5. #55
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,277
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    I never liked the way PAC works because everything is centralised around a single router/controller as an entry point (With MVC, for instance, I don't have a centralised entry point so anything can be an entry point. My own framework allows views to do this: $this->include('/userdetails/123'); which (as a simplistic example) would pull into a view exactly what you'd see within the site layout if you visited site.com/userdetails/123 which allows everything to be entirely component based and therefore reusable. PAC makes this difficult because the entry point isn't easily accessible or reusable and does too much. That was my first goal when I was exploring MVC, the more I used it the more benefits I discovered.
    Ditto in Symfony.

    And Symfony accomplishes this both elegantly and reusably.

    Quote Originally Posted by TomB View Post
    I've yet to see any framework documentation or mission statement that says why it uses the architecture it does or, more to the point, why it didn't choose others and what others it considered. I'm 100% certain that in every case no real choice was actually made through an informed decision making process.
    http://fabien.potencier.org/article/49/what-is-symfony2
    "First make it work. Then make it better."

  6. #56
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    $this->include('/userdetails/123');
    The same code in symfony would be: $crawler = $client->request('GET', '/account/register/');

    You also have the capability of filling out form fields and then getting the results of a POST. Quite handy for automated functional testing. One of the reasons that refactoring does not bother me.

    And here is another article that you might find useful: http://fabien.potencier.org/article/...ponents-part-1

    It walks you through the process of creating your own frame work without getting bogged down in creating all of you own components. I actually made a clone of CodeIgnitor following this process. Kind of fun and quite educational.

    No reason that someone with your skills and knowledge couldn't put together a "pure mvc" framework. At least a working demo.

  7. #57
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    That article states nothing about design decisions around architectures. It briefly mentions MVC but doesn't say why it chose it or indeed what else was considered. However you look at it, and whether Symfony wants to label itself a "MVC" framework or not, [url=http://symfony.com/doc/2.0/book/controller.html]it encourages a PAC architecture[/quote] and it doesn't state why this is the case.

    Quote Originally Posted by Symfony Article
    Symfony2 is really about providing the tools for the Controller part, the View part
    Which is does in in a PAC architecture with no explanation as to why.

    The paragraph there that begins with "I don't like MVC because" is laughable. Using MVC for video streaming? It's comparable to saying "I don't like hammers because they can't dig holes". Programming is always about choosing the right tool for the job (which incidentally, is my biggest gripe with the current state of affairs where nobody has made a choice). The article makes some valid points but every decent framework provides a set of reusable components, that's a non issue, and nothing special about Symfony. The whole point in the way MVC was designed in the first place is to make the components reusable.



    Quote Originally Posted by ahundiak View Post
    The same code in symfony would be: $crawler = $client->request('GET', '/account/register/');
    As I said, that was my starting point back in 2009 rather than the pinnacle of my design goal. At the time none of the frameworks I'd looked at offered it, or if they did it was in a very messy way. After I'd achieved that I came to understand what a truly modular system could offer. By splitting everything up into much much smaller modules (A generic term I'll use for an initialised stateful model, view and optional controller) which could then easily have components replaced within it.



    You also have the capability of filling out form fields and then getting the results of a POST. Quite handy for automated functional testing. One of the reasons that refactoring does not bother me.

    And here is another article that you might find useful: http://fabien.potencier.org/article/...ponents-part-1

    It walks you through the process of creating your own frame work without getting bogged down in creating all of you own components. I actually made a clone of CodeIgnitor following this process. Kind of fun and quite educational.

    No reason that someone with your skills and knowledge couldn't put together a "pure mvc" framework. At least a working demo.
    I will create a working barebones examples but unfortunately, like most of these things (you mentioned DI, and that's a good parallel) the benefits aren't obvious until you're working on a real project that's quite large.


    That said, because of this topic, I've been thinking about the simplest way of explaining the advantages of MVC and why flexibility is good... so hear me out. Consider a basic shopping cart system, there are many places I want to display *some* information about a product or order. MVC encourages reuse by making it so you only have to supply the template to achieve this. Nothing else needs to be supplied. In my current codebase for instance, I drop a template file into a specific directory call $this->getView('/orders/$templateName/$orderId') in any other template and without adding any code or changing any code in the router, controller, model or view I can use my newly created template and it already already has access to the relevant model object and can extract whatever information it likes from it. All I've done is drop a template into a directory.

    Where MVC comes into it's own in this process is that not only can I do this with templates, I can do it with models (including dropping them into a directory and having them just work, but that's my own Convention over configuration approach rather than anything to do with MVC itself).

    How about a view which displays some information about a given order. My basic model class in this scenario looks like this:

    PHP Code:
    class OrderViewModel {
        private 
    $id;
        private 
    $orderModel;
        
        public function 
    __construct(OrderModel $order) {
            
    $this->orderModel $order;
        }

        public function 
    getOrder() {
            return 
    $this->orderModel->findById($this->id);
        }

        public function 
    setId($id) {
            
    $this->id $id;
        }

    Fairly straight forward, yes? The beauty is in the simplicity. Let's say that's accessed at /orders/123. '123' gets passed to the setId() method by the controller, and the view calls the getOrder() method to access the info about the order it's going to display. Trivial stuff!

    Now. What if I wanted to display the latest order placed by a particular user? Because the system is flexible and has a proper model layer that becomes incredibly easy:

    PHP Code:
    class UsersLatestOrderViewModel {
        private 
    $id;
        private 
    $userModel;
        
        public function 
    __construct(UserModel $user) {
            
    $this->userModel $user;
        }

        public function 
    getProduct() {
            
    $user $this->userModel->findById($this->id);
            return 
    $user->getLatestOrder();
        }

        public function 
    setId($id) {
            
    $this->id $id;
        }

    I substitute the model and my view, controller and template remain totally unchanged. This is the beauty of proper encapsulation.

    (Again, this is specific to my own implementation and nothing MVC related itself but my framework allows this by simply creating the class in the right directory and then calling $this->getView('/orders/userslatestorder/999'); and it will just work without configuring the router, messing around in controller code, even looking at the template code. It'll show you the latest order for the user with the id 999 in the existing template.--And it can be configured differently if needed).

    You'd be surprised how often this is useful once you start using it. It's like DI, at first you just use it to share your dependencies, then you realise how powerful it is for keeping your code clean and reusable. To extend this example further, an admin might see a different template for an order which also showed internal product codes, which warehouse the products are stored in, etc that would never be seen by the customer. By using the exact same logic and substituting only the template any of that "Here's how I want the domain data filtered" logic becomes instantly reusable.

    Consider applying this to other parts of the shopping cart system; your basic view displays a list of products, by simply adding a new model and nothing else I can generate lists of "What's the most often ordered products?", "What products are in the user's shopping basket?", "What were the last 10 products this user ordered?", "Which were the most successful sale items?", "What are the top products among our account customers?", "Which products in this category haven't been sold in the last 6 months?" all by simply substituting the model. The beauty here is that the dependencies change. Some need information about users, some need information about products, some need information about categories. Only the model needs to know of these dependencies. What's more, these can all share the logic for searching and sorting.

  8. #58
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,277
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    That article states nothing about design decisions around architectures. It briefly mentions MVC but doesn't say why it chose it or indeed what else was considered.
    Symfony *didn't* choose MVC. For you to come away with the opposite impression makes me genuinely wonder if you actually paid attention to the article.
    "First make it work. Then make it better."

  9. #59
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Well that was my point entirely. It uses MVC because everyone else does, not because of any real decision making process.

    If you're trying to argue that "Symfony does not use MVC at all it's just a collection of classes", some of those classes are for Views and Controllers. For MVC. Which has been actively chosen to be incorporated in symfony: http://symfony.com/doc/2.0/book/controller.html . The controller class chooses to use the PAC architecture. Symfony as a framework uses PAC, there's no debate there. You proved my point entirely. Nobody put any thought into what a "controller" actually is, they simply implemented what they thought of as a "Controller" and made it available for the world to abuse.

  10. #60
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    (Again, this is specific to my own implementation and nothing MVC related itself but my framework allows this by simply creating the class in the right directory and then calling $this->getView('/orders/userslatestorder/999'); and it will just work without configuring the router, messing around in controller code, even looking at the template code.
    In Symfony, we call this using an embedded controller.

    Don't get me wrong. You got some impressive code. But so far you really have not shown anything new. And without some working code it's difficult to draw conclusions about your specific implementation.

  11. #61
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,277
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Well that was my point entirely. It uses MVC because everyone else does, not because of any real decision making process.
    Symfony *doesn't* use MVC. I don't know any other way to be more clear about this.

    Quote Originally Posted by TomB View Post
    Nobody put any thought into what a "controller" actually is, they simply implemented what they thought of as a "Controller" and made it available for the world to abuse.
    The Symfony documentation you just linked to directly contradicts you on this. It tells you -- explicitly -- what Symfony defines a controller to be. It's starting to feel like you're going out of your way to be obtuse.
    "First make it work. Then make it better."

  12. #62
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Symfony *doesn't* use MVC. I don't know any other way to be more clear about this.



    The Symfony documentation you just linked to directly contradicts you on this. It tells you -- explicitly -- what Symfony defines a controller to be. It's starting to feel like you're going out of your way to be obtuse.

    No, it uses PAC

    Again, Symfony provides View and Controller classes which use a very specific architecture. Yes you *can* hack around this to achieve something else, but all the examples use PAC and anywhere I've seen Symfony used it follows the PAC "Controller pulls some data from the model then throws it at the template" approach. Which if you remember back to the start, this was my issue. "Symfony can do that too" is not an answer to whether MVC or PAC is the better architecture.

    And this is well off topic now. As I said waaay earlier in the thread, the discussion is nothing to do with how good/bad Symfony is (I happen to think they encourage some very dubious practices such as annotations, poor separation of concerns, breaking SRP and Law of Demeter violations everywhere but that's another matter entirely) it's a discussion of the underlying architectures. I'm not sure why you interpreted "PAC isn't as good as MVC" as "Symfony is rubbish" and then attempted to turn the topic into "This is how you would achieve that in Symfony, ergo Symfony is brilliant" the discussion is solely on MVC where you separate concerns or PAC where your controller acts as a model, tightly couples itself to the view and a specific data set and it's impossible to replace the model logic because there is no model. "Symfony can do that" too is simply not an answer to this question.

  13. #63
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by ahundiak View Post
    In Symfony, we call this using an embedded controller.

    Don't get me wrong. You got some impressive code. But so far you really have not shown anything new. And without some working code it's difficult to draw conclusions about your specific implementation.

    I'll provide an example project when I get time but it's really well beyond the scope of the initial discussion because there will need to be a lot of code which is unrelated to the MVC vs PAC debate.

  14. #64
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Again, Symfony provides View and Controller classes which use a very specific architecture. Yes you *can* hack around this to achieve something else, but all the examples use PAC and anywhere I've seen Symfony used it follows the PAC "Controller pulls some data from the model then throws it at the template" approach. Which if you remember back to the start, this was my issue. "Symfony can do that too" is not an answer to whether MVC or PAC is the better architecture.
    It might be worth digging just a little deeper in order to understand why characterizing symfony as PAC may not be completely accurate and why we keep saying "ditto". Symfony is in fact perfectly capable of support your version of MVC without hacks. The online introductory documentation does target a PAC approach, mostly for simplicity and ease of getting started. But if you look through symfony applications and libraries then you can start to see that things are a bit more involved.

    Like many frame works, symfony starts off with a front controller which packages up the request and then passes it down to a chain of request listeners. The listeners can process the request and return a response or notify the request or just ignore the request completely. As you might imagine, there is an ActionListener which maps the request to a specific action method which in turn returns a response. This of course is the PAC approach.

    However, you can easily add a ModelListener would map a request to a model and then pass the model along to the rest of the listeners. Likewise, a ControllerListener and a ViewListener would complete your pure mvc implementation. None of this is either/or. You can keep the ActionListener in the chain and have a hybrid approach if you want.

    Adding these listeners are not "hacks". The system was designed from the ground up to support this sort of flexibility.

  15. #65
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    And I'll say yet again: my argument isn't against Symfony itself (Which I said several times on the first page of this topic. It never has been, this debate was always MVC vs PAC, the only reason that Symfony even got involved was that Jeff cited the manual as an example of a PAC architecture.

    That said, Symfony does advocate/demonstrate a PAC architecture in its examples. Whether that makes it a PAC framework is debatable but again, it is pushing people towards PAC and not MVC with no reasons given.

    As I said on page 1: Symfony is irrelevant to the topic at hand.

  16. #66
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,277
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    [Symfony] is pushing people towards PAC and not MVC with no reasons given.
    Even if you don't agree with the reason, there's no excuse for you to not know that there is a reason.

    I don't like MVC because that's not how the web works.

    - http://fabien.potencier.org/article/49/what-is-symfony2
    "First make it work. Then make it better."

  17. #67
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    That still isn't a reason for choosing PAC over MVC though. There is nothing to stop you giving views access to models, separating application state from domain state and avoiding the use of a controller which selects views and models.

  18. #68
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Case in point, going back to the introduction of Symfony in this topic with this article: http://symfony.com/doc/master/book/f..._symfony2.html This article demonstrates a PAC architecture. As do examples of the Symfony controller class. Whoever wrote this article made a conscious choice (Or I'm guessing they didn't actually make a reasoned choice, because they don't understand MVC) to advocate a PAC architecture.


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
  •