Page 1 of 1

Application Design / Frameworks

Posted: Thu Jun 19, 2008 5:03 pm
by EffingHell
I see that MVC (with the attendant arguments) is favoured by several here. MVC has detractors as well, just have a look at the pages at c2.com (Portland Pattern Wiki). I do not see the advantage over other architectures. An OO "pipes and filters" idea would work. In one version of MVC there is coupling between the View and the Model, which I see as less than ideal. What is wrong exactly with using more of a Mediator pattern thereby making the only tie between the View and Model be the Controller? We should keep in mind that there are many ways to achieve the end result. Isn't it just producing HTML from a request?

Re: Application Design / Frameworks

Posted: Thu Jun 19, 2008 5:06 pm
by Zoxive
I use MVC pattern to help me (the programmer) out. It helps split everything up, and make my tornado of a world more organized. It separates the logic, which as i said helps tremendously on large, or any size project.

Re: Application Design / Frameworks

Posted: Thu Jun 19, 2008 5:18 pm
by EffingHell
Zoxive wrote:I use MVC pattern to help me (the programmer) out. It helps split everything up, and make my tornado of a world more organized.
So do other app patterns. We can call the Database and Business Logic the Model, and the Page or Form a View. A Controller can tie them. Some would say you can't call that "true" MVC. And noting the way we actually handle the lifecycle of processing in PHP, I do not see why we aren't using a pipes/filters idea. If we see a FrontController something like an event handler, we choose which Controller(s) handle the event, and the subsequent controller(s) tie in the Model and produce the View.

Re: Application Design / Frameworks

Posted: Thu Jun 19, 2008 8:18 pm
by Zoxive
Its mostly the front controller that I like, and the models, and views just ice the cake for me currently.

There also isn't much limiting you from using other patterns along with the MVC.

Re: Application Design / Frameworks

Posted: Thu Jun 19, 2008 10:30 pm
by allspiritseve
EffingHell wrote:
Zoxive wrote:I use MVC pattern to help me (the programmer) out. It helps split everything up, and make my tornado of a world more organized.
So do other app patterns. We can call the Database and Business Logic the Model, and the Page or Form a View. A Controller can tie them. Some would say you can't call that "true" MVC. And noting the way we actually handle the lifecycle of processing in PHP, I do not see why we aren't using a pipes/filters idea. If we see a FrontController something like an event handler, we choose which Controller(s) handle the event, and the subsequent controller(s) tie in the Model and produce the View.
I'm curious, who is we? You make it sound as if everyone on this forum uses exactly the same architecture. True MVC in PHP is a little out of place, considering HTTP is a stateless protocol. Front Controllers and filters might be one way to set up a web application, but I think there are many more ways to do it, and it really depends on individual preferences and the scope of the project. Personally, I prefer the controllers in Konstrukt, where every URL is a nested hierarchy of resources that you can access with REST.

Re: Application Design / Frameworks

Posted: Fri Jun 20, 2008 2:39 am
by Christopher
EffingHell wrote:I see that MVC (with the attendant arguments) is favoured by several here. MVC has detractors as well, just have a look at the pages at c2.com (Portland Pattern Wiki).
As I have noted before, MVC is the only pattern that has "detractors". It's pretty funny actually (and the other patterns are jealous). What is really means is that different framework designs have detractors. I think the response to that is -- duh! And yes I have read many of those articles. You should remember that MVC is not used much for desktop apps anymore, for many of the reasons given. It is mainly a web pattern.
EffingHell wrote:I do not see the advantage over other architectures. An OO "pipes and filters" idea would work.
OK
EffingHell wrote:In one version of MVC there is coupling between the View and the Model, which I see as less than ideal.
"coupling" ? You mean that Views can access the Model?
EffingHell wrote:What is wrong exactly with using more of a Mediator pattern thereby making the only tie between the View and Model be the Controller? We should keep in mind that there are many ways to achieve the end result.
OK and obviously....
EffingHell wrote:Isn't it just producing HTML from a request?
Yes ... but you seem to be implying that design does not matter...
EffingHell wrote:So do other app patterns. We can call the Database and Business Logic the Model, and the Page or Form a View.
The names are not what define MVC. They are the pattern language used to talk about it.
EffingHell wrote:Some would say you can't call that "true" MVC.
And other programmers would say that you can call that "pure" MVC. So you have simply proved that programmers disagree.
EffingHell wrote:And noting the way we actually handle the lifecycle of processing in PHP, I do not see why we aren't using a pipes/filters idea. If we see a FrontController something like an event handler, we choose which Controller(s) handle the event, and the subsequent controller(s) tie in the Model and produce the View.
Then you have a MVC implementation that uses a Front Controller. Goto 1.

Re: Application Design / Frameworks

Posted: Fri Jun 20, 2008 5:56 am
by blueyon
MVC is just something that falls into place when creating an application.

You want to sperate the html from the code then you have the view, controller. You want to have reusable database quries so your not repeatedly writing SQL then you create classes with methods that can be called throughout your application (The model).

Re: Application Design / Frameworks

Posted: Fri Jun 20, 2008 10:11 am
by EffingHell
allspiritseve wrote:I'm curious, who is we? You make it sound as if everyone on this forum uses exactly the same architecture. True MVC in PHP is a little out of place, considering HTTP is a stateless protocol. Front Controllers and filters might be one way to set up a web application, but I think there are many more ways to do it, and it really depends on individual preferences and the scope of the project. Personally, I prefer the controllers in Konstrukt, where every URL is a nested hierarchy of resources that you can access with REST.
Great reply. Thanks, allspiriteve. I'm checking out Konstrukt now. One of the nice things from the first look is that it includes the technologies as part of the problem/solution domain.

As far as who the "we" is, I have been reading PDN and found that several folks on the forum were big fans of MVC.

Re: Application Design / Frameworks

Posted: Fri Jun 20, 2008 10:21 am
by EffingHell
Let me start by apologizing for what could be taken as an irritated tone in my posts yesterday. It's just frustration.
arborint wrote:As I have noted before, MVC is the only pattern that has "detractors". It's pretty funny actually (and the other patterns are jealous). What is really means is that different framework designs have detractors.
Actually, the pattern itself has detractors.
arborint wrote:You should remember that MVC is not used much for desktop apps anymore, for many of the reasons given. It is mainly a web pattern.
Disagree, it is used for many. It is used in at least two of the Carbon APIs I have read, and my understanding is it is used in several M$ apps as well.
arborint wrote:"coupling" ? You mean that Views can access the Model?
Yes.
arborint wrote:Yes ... but you seem to be implying that design does not matter...
I'm not sure how you got that. Design matters. Design is fundamental.
arborint wrote:The names are not what define MVC. They are the pattern language used to talk about it.
arborint wrote:And other programmers would say that you can call that "pure" MVC. So you have simply proved that programmers disagree.
Indeed. My comments, however, come from reading this forum yesterday.

Again, my apologies. I should have gathered the quotes from the hundreds of posts I read yesterday and made a more coherent complaint.

Re: Application Design / Frameworks

Posted: Fri Jun 20, 2008 10:28 am
by allspiritseve
EffingHell wrote:As far as who the "we" is, I have been reading PDN and found that several folks on the forum were big fans of MVC.
Well, just because several people are MVC fans doesn't mean we all use the same architecture. I think we disagree much more than we agree on most things. Which isn't necessarily a bad thing.

Konstrukt feels much more natural to me than the typical /controller/method/ approach. It works great with mod_rewrite, and doesn't try to do everything for you... just gives you a little jumpstart to organizing your code.

Re: Application Design / Frameworks

Posted: Fri Jun 20, 2008 10:39 am
by EffingHell
allspiritseve wrote:Well, just because several people are MVC fans doesn't mean we all use the same architecture.
I didn't intend to imply that. I had said: "I see that MVC (with the attendant arguments) is favoured by several here".
allspiritseve wrote:I think we disagree much more than we agree on most things. Which isn't necessarily a bad thing.
Agreed. :D

Re: Application Design / Frameworks

Posted: Fri Jun 20, 2008 12:13 pm
by Christopher
No reason to apologize. You just shambled into the biggest, most ridiculous design topic there is... ;)

As to MVC having its "detractors", you have to understand my point that words like "detractors" are only used for MVC. There are not group vehemently against the Decorator or Facade pattern. Probably ActiveRecord is the only one that comes close, and it is because in both cases the argument in about much more than the pattern itself. If you don't think MVC is an appropriate solution to your problem then don't use it -- that's sort of the point of patterns.

So to get to MVC specifically, you need to be clear of whether the people here who are "fans" of MVC are fans of one or more MVC frameworks, or are do they use the two separations and related dependencies that MVC defines. Either of those is an informative discussion.

As far as Konstrukt, it does in fact implement the MVC pattern in essence. It has Controllers and Views, and does not implement the Model which assumes that it would properly be in the Domain Layer below the Presentation Layer. I doubt that Troels would disagree with my statement. It's actually a very nice, simple implementation of a Front/Action Controller style MVC framework.