I think you are mixing things up here. Use of a pattern or a set of patterns may become a "standard" (using the term loosely) for certain types of applications, but that does not make the terms synonymous. Use of an algorithm or methodology may become a standard as well, but it does not make the terms algorithm or methodology the same as standard. While Standard and Pattern may have some general meanings, they have very specific meanings in the software world.mudvein wrote:Standard and Pattern are loose terms in general. If you use, what you call a Pattern, as the direction in which your code will be built, it actually does become a standard...
So I think both of you are correct. MVC may be a pattern, but it's also a standard. A standard is a set of patterns you use to create code.
Advice needed for MVC, FrontController, etc
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
(#10850)
Not to argue here, but take this "For instance" example.arborint wrote:I think you are mixing things up here. Use of a pattern or a set of patterns may become a "standard" (using the term loosely) for certain types of applications, but that does not make the terms synonymous. Use of an algorithm or methodology may become a standard as well, but it does not make the terms algorithm or methodology the same as standard. While Standard and Pattern may have some general meanings, they have very specific meanings in the software world.mudvein wrote:Standard and Pattern are loose terms in general. If you use, what you call a Pattern, as the direction in which your code will be built, it actually does become a standard...
So I think both of you are correct. MVC may be a pattern, but it's also a standard. A standard is a set of patterns you use to create code.
A company XYZ uses the MVC "Pattern" to write their code. They make it the one way their developers create applications, and how their creative services group design their pages. This now becomes a "Standard" because it's the standard way for them to develop.
Outside of that scope, MVC is still a "Pattern", but inside the scope it's a "Standard".
As I said, both are correct...
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Your scope is highly specific to one organisation or peer group though. Outside the group MVC is still not a standard. Even in a group, it shouldn't become a standard per se - the implementation not the pattern becomes an enforced standard. It's be a weird set of developers who insist there's a one true way to do MVC...
.
I hesitated on contributing to the discussion until now, but this comment lends itself to my point of view.Maugrim_The_Reaper wrote:It's be a weird set of developers who insist there's a one true way to do MVC....
I get beaten down fairly often for using the phrase "seperating my html from my php". However, it comes from the fact that it is an accurate description of what I do, despite the hand-waving of various pundits.
Its not truly seperating view from the model or controller - because even the most basic dynamic content will have some form of logic operating in the template. Whether its a simple if/else for logged in users, or a "when date = easter, show eggs" item, almost all templates have some conditional, some logic, some processing.
That means that its not truly MVC. Some people prefer the more general pattern of Data/Logic/Presentation, but even that doesn't consistently apply - again, because the presentation layer will contain some processing.
In other languages, you can honestly get much closer to a true MVC or DLP seperation, which is why those patterns are idealized.
Applying them rigidly in PHP is simply a recipe for inaccuracy or disaster. Which is why I prefer saying I'm seperating my html from my php. In my templates, you find (mostly) raw html. You don't find it in my php files (once I'm done converting them). So my statement IS accurate, if a little simplistic and confusing at the same time.
My advice with MVC, and with OOP, and with pretty much everything else in programming, is to take it in moderation. So you can't get absolutely pure MVC seperation, so what?
The reason patterns exist is because over time, multiple programmers have faced the same problem, and found similar solutions, and found few flaws with them. Its a bit like science - you might find other solutions, but there might be flaws with it, so it doesn't become a pattern.
Similarly, once a pattern is used widely enough, it becomes a standard. If it remains long enough, it could even become "best practice", recommended widely by virtually everyone.
But its crucial to remember that while patterns and standards are generally correct, in the majority of cases, they do not always make the best solution to YOUR problem. Thats why MVC purists don't belong in PHP - because the language, at its core, is designed to mix all three. It started as a templating language with db hooks, and everything that has come since is simply a refinement of that core.
Or put much more simply: All generalizations suck.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I think this is an interesting statement because separating your HTML and PHP is a really important first big step in PHP programming. I think it is the one that gives the greatest benefits because it changes PHP from a templating language to a programming language. However, once that it done it becomes pretty obvious that PHP is an incredible templating language as well. That's true of of only a few other language and even then PHP is the king.Roja wrote:I get beaten down fairly often for using the phrase "seperating my html from my php". However, it comes from the fact that it is an accurate description of what I do, despite the hand-waving of various pundits.
Which I think leads to a much better definition of where the first separation should occur for PHP programmers -- that is "separating my templating from my programming." I think most PHP programmers can clearly visualize that, and that clearly separates the View as all the "templating" stuff. That leaves the rest of your code. If you can then define what is the domain code and separate that out into the Model -- viola, the rest is the Controller. I think it is easier to do in PHP when you think about it in PHP's terms. And luckily MVC is high level so the details depend on the implementation leaving a lot for programmer creativity.
(#10850)
I am not a PHP Guru like many of you are, however MVC goes well beyond PHP and programming. So when I first jumped into PHP the first thing I tried to do was define and separate into MVC and I feel I did it without any problems. I have my View which is my templates (HTML, CSS, JS), I have my Controller which determines what templates to load, what classes to load, and what methods should be called, and then I have my Model which are all classes. The database (like someone was trying to say) is not your model. The database is seperate as it has its own model along with other things. This is not to be confused with a db abstraction layer which would fall under your model and makes calls to your database.
Now I do build from the ground up without any framework like PEAR so I am not sure how that would effect my view of MVC in PHP, though I am sure it would change things.
Now I do build from the ground up without any framework like PEAR so I am not sure how that would effect my view of MVC in PHP, though I am sure it would change things.