Application Design / Frameworks
Moderator: General Moderators
-
EffingHell
- Forum Newbie
- Posts: 6
- Joined: Thu Jun 19, 2008 4:50 pm
Application Design / Frameworks
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
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.
-
EffingHell
- Forum Newbie
- Posts: 6
- Joined: Thu Jun 19, 2008 4:50 pm
Re: Application Design / Frameworks
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.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.
Re: Application Design / Frameworks
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.
There also isn't much limiting you from using other patterns along with the MVC.
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Application Design / Frameworks
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.EffingHell wrote: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.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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Application Design / Frameworks
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 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).
OKEffingHell wrote:I do not see the advantage over other architectures. An OO "pipes and filters" idea would work.
"coupling" ? You mean that Views can access the Model?EffingHell wrote:In one version of MVC there is coupling between the View and the Model, which I see as less than ideal.
OK and obviously....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.
Yes ... but you seem to be implying that design does not matter...EffingHell wrote:Isn't it just producing HTML from a request?
The names are not what define MVC. They are the pattern language used to talk about it.EffingHell wrote:So do other app patterns. We can call the Database and Business Logic the Model, and the Page or Form a View.
And other programmers would say that you can call that "pure" MVC. So you have simply proved that programmers disagree.EffingHell wrote:Some would say you can't call that "true" MVC.
Then you have a MVC implementation that uses a Front Controller. Goto 1.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.
(#10850)
Re: Application Design / Frameworks
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).
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).
-
EffingHell
- Forum Newbie
- Posts: 6
- Joined: Thu Jun 19, 2008 4:50 pm
Re: Application Design / Frameworks
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.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.
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.
-
EffingHell
- Forum Newbie
- Posts: 6
- Joined: Thu Jun 19, 2008 4:50 pm
Re: Application Design / Frameworks
Let me start by apologizing for what could be taken as an irritated tone in my posts yesterday. It's just frustration.
Again, my apologies. I should have gathered the quotes from the hundreds of posts I read yesterday and made a more coherent complaint.
Actually, the pattern itself has detractors.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.
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: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.
Yes.arborint wrote:"coupling" ? You mean that Views can access the Model?
I'm not sure how you got that. Design matters. Design is fundamental.arborint wrote:Yes ... but you seem to be implying that design does not matter...
arborint wrote:The names are not what define MVC. They are the pattern language used to talk about it.
Indeed. My comments, however, come from reading this forum yesterday.arborint wrote:And other programmers would say that you can call that "pure" MVC. So you have simply proved that programmers disagree.
Again, my apologies. I should have gathered the quotes from the hundreds of posts I read yesterday and made a more coherent complaint.
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Application Design / Frameworks
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.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.
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.
-
EffingHell
- Forum Newbie
- Posts: 6
- Joined: Thu Jun 19, 2008 4:50 pm
Re: Application Design / Frameworks
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:Well, just because several people are MVC fans doesn't mean we all use the same architecture.
Agreed.allspiritseve wrote:I think we disagree much more than we agree on most things. Which isn't necessarily a bad thing.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Application Design / Frameworks
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.
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.
(#10850)