Is MVC now the only way to write PHP? [closed]_问答_开发者

Closed. This question is off-topic. It is not currently accepting answers.

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

开发者_如何学Python

Closed 12 years ago.

Improve this question

The vast amount of frameworks available for PHP now use MVC. Even ASP.net has its own MVC module.

I can see the attraction of MVC, I really can and I use it frequently. The only downside that I can see is that you have to fire up the whole system to execute a page request. Depending on your task this can be a little wasteful.

So the question. In a professional environment is this the only way to use PHP nowadays or are their other design methods which have alternative benefits?

I don't like anyone telling me how to write a code. If I want to use MVC I will, if I find a better way that solves specific task, I will use it. I don't like when people turn MVC into a religion. I also think many php coders misunderstand the MVC concept and think they are using MVC pattern when in fact most of the times that are not using a 100% pure MVC. The truth is that it's not easy nor very efficient to write a website that is 100% MVC and is written in php.

Most people having most difficulties in the "V" part of the MVC. The "M" is easy. It's your data. If you storing your data in the database and have a database access class, that's your "M" part, you good with "M"

Now the controller: when user clicks on any link of your page, your php code must get the data from the "M" (database), prepare it, apply some logic like adding personalization to logged in user, adding "please login" link if user not logged it, etc. This is your "C" part.

The problem that most people are having with is separating the "V" View from "C" (controller) This is not easy nor is it the most efficient way to code in php. In many cases the controller part must already generate some html, so you blur the line between controller and view.

If you want to stay pure MVC then you must make sure that your controller returns a pure data, then the View class takes some template, plugs in your data and returns the HTML. This is where the problem lies in php. There is no easy and efficient way to do templating where a template just takes a pure data as input and returns the html. If there was an easy way, then there would not be reason for people to keep coming up with yet another new template library. The reason the there are so many templating libraries for php is because there are always programmers that are not happy with ANY of the existing ones and keep trying to invent their own, better one.

The only pure templating library in my opinion is the XSLT, which is fully supported by php, it's comes with php, it works, it's powerful, great templating engine, better yet, it's a standard, platform independant language. Once you learn XSLT you can use it in any other programming language like Java. But it does have one tiny problem, however. It requires the input to be an XML. Sure, you can create a great, 100% valid XML in php also using DOM library which is also part of php. The problem is that it will be slow. You will be doing double the work: first creating XML from your array of data, then trasforming that XML into HTML with your XSL template. This is why the approach of XSLT as templating engine never took off in php.

Now you left with the other options to parse templates, usually its regex based approach. You see how it always gets complicated when we get to the "V" part of the MVC?

The "M" is easy, the "C" is some type of pure php code, be it OOP or procedural code, does not matter. It's the "View" that is the tricky one.

So my advice is - don't worry too much about sticking to pure MVC. It's OK for a controller to spit out chunks of html here and there.

Well there are a lot of other approaches.

MVC is just popular because it suits most situations (or better said can be used in most situations) and has established itself as a de-facto standard.

What can be said is that every programming/design pattern - or more specific architectural - depends on some classification.

Those are often (of course they can be devided further):

User Interface (pretty images, forms etc)
Application (your application logic and stuff that needs to be secured from the client - ak lot of that can often be done in the user inteface, eg. by javascript)
Database - self explaining
Infrastructure (very basic stuff like hard disk, server systems, network etc.)

Of course there is always the naive, procedural straight-forward approach but also a lot fo other patterns that can link and structure the access and controlling to these basic layers.

Mvc is one of them. But here are some example of others:

http://en.wikipedia.org/wiki/Model_View_ViewModel

http://en.wikipedia.org/wiki/Model_View_Presenter

Is MVC-ARS preferable to classic MVC to prevent overloading?

And here a lot more:

http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)