Only if you refuse to consider alternatives. If you have a good reason why you do it that way we'll all be interested to hear it. If you don't then you are probably using an inferior technique.is just end with us both being blue in the face.
On Frameworks, RoR & PHP
Moderator: General Moderators
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
I also don't get why there is any discussion about the MVC pattern.. the pattern is simple, yet it's always made out to be some vastly complex device.. it's not. You separate your Model logic, from your View logic, from your Controller logic. That is plain and simply it. There is no "history" there is no "evolution" there is only other design patterns, which can be used in conjunction with the Model, View, and Controller pattern, and any other pattern.
There is also this apparent obsession people have with the heuristics of design patterns. Did you know that you don't have to have separate objects to satisfy the MVC pattern, for example? If you have one method which decides - that's your controller. If you have another method that does nothing but present the outcome, that's your view. Another method to crunch numbers? That's your model.
Even a Procedural script can satisfy the MVC pattern, with ease.
MVC is one, single pattern. It is not a metaphor for "Design Patterns", it is not a collection of patterns, it is most certainly not a synonym for "What Martin Fowler would do."
It also seems people fail to recognise these patterns are guidelines, not rigid boundaries. We all like to have a well oiled running machine, but the moment anything gets as ridiculous as "That doesn't fit in with my interpretation of MVC" then you are just being a jobsworth/pedant.* If it works, and works as well as it can, and is easily maintainable, why change it? Because PoEAA says so?
*Now who's going to quote that and take it right out of context with a reply such as "Well let's just scrap the whole book of patterns then, shall we?"
There is also this apparent obsession people have with the heuristics of design patterns. Did you know that you don't have to have separate objects to satisfy the MVC pattern, for example? If you have one method which decides - that's your controller. If you have another method that does nothing but present the outcome, that's your view. Another method to crunch numbers? That's your model.
Even a Procedural script can satisfy the MVC pattern, with ease.
MVC is one, single pattern. It is not a metaphor for "Design Patterns", it is not a collection of patterns, it is most certainly not a synonym for "What Martin Fowler would do."
It also seems people fail to recognise these patterns are guidelines, not rigid boundaries. We all like to have a well oiled running machine, but the moment anything gets as ridiculous as "That doesn't fit in with my interpretation of MVC" then you are just being a jobsworth/pedant.* If it works, and works as well as it can, and is easily maintainable, why change it? Because PoEAA says so?
*Now who's going to quote that and take it right out of context with a reply such as "Well let's just scrap the whole book of patterns then, shall we?"
C'mon Ole! Are you just being argumentative here? Did you read that entire paragraph? This conversation doesn't need to be had. Don't be a McGruff.ole wrote:Only if you refuse to consider alternatives. If you have a good reason why you do it that way we'll all be interested to hear it. If you don't then you are probably using an inferior technique.is just end with us both being blue in the face.
Ever read what Joel Spolsky has to say about Architect Astronauts?Jenk wrote: I also don't get why there is any discussion about the MVC pattern.. the pattern is simple, yet it's always made out to be some vastly complex device.. it's not. You separate your Model logic, from your View logic, from your Controller logic. That is plain and simply it. There is no "history" there is no "evolution" there is only other design patterns, which can be used in conjunction with the Model, View, and Controller pattern, and any other pattern.
There is also this apparent obsession people have with the heuristics of design patterns. Did you know that you don't have to have separate objects to satisfy the MVC pattern, for example? If you have one method which decides - that's your controller. If you have another method that does nothing but present the outcome, that's your view. Another method to crunch numbers? That's your model.
Even a Procedural script can satisfy the MVC pattern, with ease.
MVC is one, single pattern. It is not a metaphor for "Design Patterns", it is not a collection of patterns, it is most certainly not a synonym for "What Martin Fowler would do."
It also seems people fail to recognise these patterns are guidelines, not rigid boundaries. We all like to have a well oiled running machine, but the moment anything gets as ridiculous as "That doesn't fit in with my interpretation of MVC" then you are just being a jobsworth/pedant.* If it works, and works as well as it can, and is easily maintainable, why change it? Because PoEAA says so?
*Now who's going to quote that and take it right out of context with a reply such as "Well let's just scrap the whole book of patterns then, shall we?"
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
No, not kidding. I know you can both understand it and implement it. You need to look at the influence of N-Tier on the original MVC concept which gives us the Model 2 MVC that we consider as "MVC" today. That MVC in in two tiers is significant to understanding the pattern. All these patterns are the result of common problems that people have found common solutions for.BDKR wrote:You're kidding right? Oh, I get it. You mean to assume that I can't understant that, much less implement it, with my own harvested framework. Oohhhh clever you, but you're wrong.arborint wrote: MVC plays off of N-Tier ....![]()
I think your distillation of "Then we can eliminate the switch and replace it with polymorphism" is significant. And I hope you have noted above that I have repeatedly said that design smell and anti-patterns may indicate a problem (especially if you don't understand the problem). They are not commandments.
However, I think the think you are overlooking (in MVC) the cascade of effects that occur when you change from switch to dispatching Commands (polymorphism) that has become central to MVC. One you make that change then a bunch of other good (and pesky) things happen -- that is why I say that some of these higher level patterns are not so insular as the simpler GoF ones.
I was using state in a similar meaning to practice ... sorry if there was some confusion.BDKR wrote:The current state of it? There are others? Don't confuse 'state', however vague that may be, with 'practice'. What's obvious here is that I don't embrace the current practice. Plain and simple as that.
I am not arguing with you personally, but about the meaning and practice of MVC. I assume that people will come to their own conclusions from what they read. But I, like you, think it is important that the information we think is important is presented. I feel strongly about MVC because implementations often vary from the pattern (e.g., RoR and ZF) because of knowledge or lack thereof by the developers. Those developers implemented short-cuts to achieve specific goals. The trade-offs were apparently worth it. But those variations can also cause confusion when trying to understand MVC.BDKR wrote:Look. I know what you are saying and actually understand it. In professional settings (which aren't allways that professional) i've played ball and made use of MVC in it's more current practice (RonR in particular). As an individual and for my own projects, I choose to do something else. Plain and simple as that. Continued... is just end with us both being blue in the face.
(#10850)
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
It is that simple when written in plain English yes. But you're mad if you would not describe MVC as a complex pattern. It is a complex pattern until you get used to it. It may not seem complex to you right now but I bet it was complex when you first started to fathom it out. Of all the common design patterns MVC is definitely right up there in terms of complexity.Jenk wrote:I also don't get why there is any discussion about the MVC pattern.. the pattern is simple, yet it's always made out to be some vastly complex device.. it's not. You separate your Model logic, from your View logic, from your Controller logic. That is plain and simply it.
To a point, I agree with you. But the idea of MVC in simplicity is something that is rather easily arrived at. I think it's important to stress "arrive" because that tends to nod towards what Martin Fowler says about Harvested Frameworks. I feel also that the process of discovery, experience, and reflection (not meant in the Comp-Sci way) that is part of harvesting a framework is exactly the same as the one for patterns, but with no formalization.d11wtq wrote: It is that simple when written in plain English yes. But you're mad if you would not describe MVC as a complex pattern. It is a complex pattern until you get used to it. It may not seem complex to you right now but I bet it was complex when you first started to fathom it out. Of all the common design patterns MVC is definitely right up there in terms of complexity.
I'm drifting.
I said the above to say that MVC really is simple as a concept. The actual practice of MVC isn't allways so simple, but that's something we as developers understand anyways right?
Full uptake of current practice is where complexity begins to creep in. Now that's not to say that all of that complexity is bad. Some of it just is and there is no way around it. But ultimately, many have arrived at something that is very much like MVC (simply because it's so obviously good) before they had formal understanding of it as such.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I don't think you are drifiting and you make a significant point. For those not familair with the concept of Harvested Framework it is worth a quick read as it is an invaluable insight into software development (See TDD, Premature Optimization, YAGNI, etc.).
For MVC, I don't think it is as simple as you say. MVC divides an application into tree parts in two layers with defined but flexible dependencies. If you stop at "... three parts" it is simple -- it is the rest that makes it not so simple in my eyes.
Perhaps Harvesting could be the method that we investigate the next-gen of frameworks and look at the callback/dispatch and template/generated ideas. We pick some example problems (e.g., a login page) and build non-framework code solving the problem in various ways ... the refactor.
For MVC, I don't think it is as simple as you say. MVC divides an application into tree parts in two layers with defined but flexible dependencies. If you stop at "... three parts" it is simple -- it is the rest that makes it not so simple in my eyes.
Perhaps Harvesting could be the method that we investigate the next-gen of frameworks and look at the callback/dispatch and template/generated ideas. We pick some example problems (e.g., a login page) and build non-framework code solving the problem in various ways ... the refactor.
(#10850)
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Argumentative?! I'm not argumentative! OK that was a joke. I've said everything I wish to say nowC'mon Ole! Are you just being argumentative here? Did you read that entire paragraph? This conversation doesn't need to be had.
Interesting. Perhaps we're all guilty of that by being in this thread.Ever read what Joel Spolsky has to say about Architect Astronauts?
I wasn't familiar with the term but the concept, yes, very much so. I'm practising it at the moment. I would recommend it to anyone especially in a business environment where you have to be seen to be producing functionality, you don't have time to stop and write a library or a framework.For those not familair with the concept of Harvested Framework
That's exactly my point, though.. it is "that simple." MVC pattern is not relevant to you using loose coupling or direct globals. It does not relate to whether you use a factory, it does not relate to if you use an Observer, or a bog-standard Iterated List of components. All that matters for MVC is that there is only View/Presentation logic in the area dubbed "The View" (be it a complete object, a method of an object, or even a specific code block of your procedural script) and so on. I'd also argue 3 parts = 3 layers, but that's a different topic.arborint wrote:For MVC, I don't think it is as simple as you say. MVC divides an application into tree parts in two layers with defined but flexible dependencies. If you stop at "... three parts" it is simple -- it is the rest that makes it not so simple in my eyes.
RE: Harvested Framework - now that is interesting, if for nothing more than I am currently doing exactly that with a project at work (by chance more than by design I must add) and perhaps it's more than coincidence that it has found it's way into this thread. Who knows.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I agree that there are many possible implementations and that it does not necessarily dictate using specific patterns -- but current practice does. And a for 3 layers ... you need to read the history of 3-Tier and MVC to see how they relate. MVC is definitely only 2 layers. That's the hardest part about it -- that the V and C are in the same layer.Jenk wrote:That's exactly my point, though.. it is "that simple." MVC pattern is not relevant to you using loose coupling or direct globals. It does not relate to whether you use a factory, it does not relate to if you use an Observer, or a bog-standard Iterated List of components. All that matters for MVC is that there is only View/Presentation logic in the area dubbed "The View" (be it a complete object, a method of an object, or even a specific code block of your procedural script) and so on. I'd also argue 3 parts = 3 layers, but that's a different topic.
(#10850)
And that seems exceptionally strange to me. I noted that with RonR and other PHP f-works (as in frameworksarborint wrote: That's the hardest part about it -- that the V and C are in the same layer.
Code: Select all
<?php
/**
* Controls the application
*/
class ProductController extends ProductView {
//! A constructor.
/**
* Constucts a new ProductController object
* @param $model an instance of the ProductModel class
* @param $getvars the incoming HTTP GET method variables
*/
function ProductController (&$model,$getvars=null) {
ProductView::ProductView($model);
$this->header();
switch ( $getvars['view'] ) {
case "product":
$this->productItem($getvars['id']);
break;
default:
if ( empty ($getvars['rownum']) ) {
$this->productTable();
} else {
$this->productTable($getvars['rownum']);
}
break;
}
$this->footer();
}
}
?>There is a cleaner way to do this.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
The giveaway is "class ProductController extends ProductView" -- right there they are stating that there is no separation between Controller and View. But I do want to point out: THAT'S OK. Combining the Controller and View is a perfectly reasonable thing to do in some cases -- usually because the problem is so simple. Now if you combine the Model with the View or Controller then you are creating a Transaction Script. THAT'S NOT AS OK.BDKR wrote:In keeping with the idea of seperating V and C, the above seems to spit right in it's face.
There is a cleaner way to do this.
You noticed that RoR does not do clean VC separation. That is mainly because they did not choose to. You may also notice that Zend Framework does not do it as well. That is mainly because they didn't know how and couldn't figure it out.
There is nothing wrong with N-Tier where the Model and Presentation are in different layers (V and C combined). But you need to answer the question: What are the benefits of separation the View and Controller if it is so hard to do and yet people keep talking about it? I would like this thread to tackle this issue and show what the options are to the code above. Maybe that's the best way...
(#10850)
Wow, I'm surprised more haven't had anything to say on this topic. But then, everybody else was probably gelling over the last couple of days like the way I was. I didn't do a thing all day yesterday (until 9 PM until I started working on the design of another site) except practice guitar and watch "The Revolution" on the History Channel all day long. Awesome series!
1) Flexibility.
2) Cleaner design.
Because of number 2 (and based on how it's executed), there should be the extra pleasentry of being able to quickly grok potential logic paths (differing requests) with just a casual glance of the code.
What I do is kind of an MVCC approach. One controller is specifically for Views and the other controller is for logic. The controllers themselves don't have any actual code other then the name of a method or function that will take care of the requested operation. The logic controller is allways interogated first in advance of any output of markup. The view controller is then pased the output from whichever logic operation was run.
I'll try to hack out some simple example code later if that doesn't make any sense.
Cheers
I don't see why it's so hard to do this, but your question of the need is a good one. To me, it's allways been two things.arborint wrote: There is nothing wrong with N-Tier where the Model and Presentation are in different layers (V and C combined). But you need to answer the question: What are the benefits of separation the View and Controller if it is so hard to do and yet people keep talking about it? I would like this thread to tackle this issue and show what the options are to the code above. Maybe that's the best way...
1) Flexibility.
2) Cleaner design.
Because of number 2 (and based on how it's executed), there should be the extra pleasentry of being able to quickly grok potential logic paths (differing requests) with just a casual glance of the code.
What I do is kind of an MVCC approach. One controller is specifically for Views and the other controller is for logic. The controllers themselves don't have any actual code other then the name of a method or function that will take care of the requested operation. The logic controller is allways interogated first in advance of any output of markup. The view controller is then pased the output from whichever logic operation was run.
I'll try to hack out some simple example code later if that doesn't make any sense.
Cheers
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Indeed, it's common that in your controller you'll just push data into properties, or through a method which acts as a transport to get the data to the template. I do this myself using __get() and __set(), then building variable-variables before including the template file. I've seen this approach more than once before too.arborint wrote:The giveaway is "class ProductController extends ProductView" -- right there they are stating that there is no separation between Controller and View. But I do want to point out: THAT'S OK. Combining the Controller and View is a perfectly reasonable thing to do in some cases -- usually because the problem is so simple.BDKR wrote:In keeping with the idea of seperating V and C, the above seems to spit right in it's face.
There is a cleaner way to do this.
I go as far as building interfaces and abstracts for "Viewable" components (page templates and view helpers). All these do pretty much is act as a container for variables (model data) which will appear visible in the template files. The controller holds an instance of the view, pushes variables into it, then asks the view to "render" itself. View::render() just iterates over all the variables it collected through View::setVar(), creates $$variables, then include()'s the template file. There is a clear coupling between the controller and the view though so arguably it's pointless having the two classes:arborint wrote:There is nothing wrong with N-Tier where the Model and Presentation are in different layers (V and C combined). But you need to answer the question: What are the benefits of separation the View and Controller if it is so hard to do and yet people keep talking about it? I would like this thread to tackle this issue and show what the options are to the code above. Maybe that's the best way...
(pseudo) transport for data to view from controller:
Code: Select all
protected function __set($varname, $value) {
$this->view->setVar($varname, $value);
}Code: Select all
public function executeMyAction() {
if ($this->request->has("userid")) {
$user = User::retrieveById($this->request->get("userid"));
$this->user = $user;
}
}Code: Select all
public function render($file) {
foreach ($this->tplVars as $k => $v) {
$$k = $v;
}
include $file;
}EDIT | Fixed error in exmaple code $this->view->user should have been $this->user.
- kyberfabrikken
- Forum Commoner
- Posts: 84
- Joined: Tue Jul 20, 2004 10:27 am
This is where a separate assembly layer comes in. The controller "decides" which model components it needs - so to speak - in the assembly layer. A simple, yet powerful, solution, is to pass the dependencies in the constructor, and encapsulate the creation in a factory. This factory can be put in a common assembler, with factories for all your applications objects. Such an assembler is called a service locator, a registry or a dependency injection container, depending on how it's implemented.d11wtq wrote:Back to the example code posted, I'm not folowing it too well. Who decides what $model should be passed to the constructor :? Surely that's the controller's job to pull in Model itself? Maybe the view needs more than one model too. The code almost suggests that each page has a known model.... this goes very much against the way I think MVC should work. Controller holds a great deal of responsibility for everything that happens so making Controller too tightly coupled to anything else just reduces flexibility IMHO.
... is just end with us both being blue in the face.