7 Answers
7

There are different patterns in software development like MVP, MVVM, MVC, etc. are some of the well-known once. However, you have to define the specific problem or technology that you are intending to solve or use.

Each pattern that i have counted are good to solve some specific sets of problems. For example MVP (Model View Presenter) pattern, helps to introduce separation of concerns in ASP.NET Web forms development. It refers to splitting up the responsibilities for gathering, displaying, and storing data from a web page into separate objects: a Model object, a View object, and a Presenter object.

+1 are we going to live with MVC defined as a pattern, or a technique which will see soon or near see it's successor?
–
IndependentJul 26 '12 at 5:15

4

+1 but MVP, MVVM and MVC are all variations of the same theme: separating (g)ui from model logic and having some third party (controller, presenter) mediate between them.
–
Marjan VenemaJul 26 '12 at 6:34

what is the best design pattern for web and php? i worked with PHP frameworks but i want to know is there pattern simple and clear than MVC?
–
Mr-MoqadamJul 26 '12 at 7:18

2

@Mr-Moqadam: MVC looks like an overkill and complicated at first. It does what you should do, separating UI, logic and data. The only thing that's sure in software development is change. And as a rule of thumb; 20% is development, 80% is maintaining. From that perspective, MVC is surely worth the effort. It's also the most basic pattern to achieve this, I guess.
–
Bruno SchäpperJul 26 '12 at 7:30

2

@Mr-Moqadam: No, it helps you a lot, even if you are alone. And especially in large projects.
–
Bruno SchäpperJul 26 '12 at 9:59

A nice pattern, which I came accross a few weeks ago, is MOVE.
It looks a bit more sophisticated as MVC, but is based on the same principle.
One downside of MVC is your controllers can get really, really big. Using the MOVE pattern, you'll handle this issue, a little bit.

So it does, but in reality controllers tend to get pretty fat.
–
Jan_VJul 26 '12 at 11:56

2

That's because you put domain logic into controllers, which wasn't the intention of the original Krassner&Pope kind of MVC. Controllers in the original fashion are about input handling, eg. connecting mouse clicks on (X,Y) coordinate into a model operation (like, increasing temperature in a thermostat app). That said, most of the controller layer in the MVC sense is fully-automated, and therefore, invisible to the application developer in a framework.
–
AadaamJul 26 '12 at 13:25

The first thing to establish is what exactly you need to do, to decide whether or not a framework and/or MVC (or other design pattern) would be of benefit.

Frameworks are there to provide a consistent platform for development whilst usually providing solutions to common programming requirements (such as Database interaction, form creation and validation, user authentication etc.)

For PHP at least the MVC / HMVC design pattern does tend to dominate the mainstream frameworks available (e.g. Zend, CakePHP, CodeIgniter etc.) but there are many different design patterns that one could use.

MVC is so popular because it offers an established and understood way of separating data modelling and processing logic from view/presentation layer (something which is considered desirable in order to produce robust, scalable applications).

It's important to note (and as was expressed by @Marjan Venema in a comment to @ElYusubov's answer) that MVC, MVP, MVVM and the other MVx patterns are (in principal at least) all the same 'design pattern'.

Typically different design patterns all serve (often subtly) different purposes and in several cases were developed with a specific language in mind. However a true 'design pattern' is not a hard and fast rule to programming and is really more of a philosophical / idealogical understanding of a programs implementation and design requirements and logical function(s).

Research is the best way to find out about different programming principals and best practices, here's some Wikipedia links to get you started:

In practice there's nothing stopping you from implementing your own 'pattern', IMO the best way is to learn by doing, for me at least I didn't fully understand the MVC pattern until I started trying to write a web site using it.

Once you understand some of the programming concepts and best practices you can use those to build your own system to solve the specific problems you're facing and to meet your needs, whether it conforms to an established 'pattern' or not.

If you have no specific set of problems to solve then learning one of the common frameworks is your best bet.

As ElYusubov pointed out, the ASP.Net framework has long had MVP and MVVM patterns, if you are looking for relatively mainstream examples. One of the main differences between MVC and MVVM is how your entities are updated; MVC is better suited to the traditional stateless or semi-stateless approach of web applications. The ASP.Net framework tried to work around this by keeping your state embedded in a form (so it could be restored on each request), which made the MVP and MVVM patterns make more sense there.

With HTML5, applications are becoming more and more JavaScript-heavy, with much of their state being on the client. This may lead to a resurgence in MVVM frameworks, and Knockout JS is one example.

Most patterns in the wild are MVC, or some flavor of MVC. After all it makes sense to split up your data (Model), the representation (View) and interaction with it (Controller). If you have a look at MVC as it was founded in the 80's, you will find out it was never meant to be a web framework. Thus i found it to be far overburden in the web.

An other well known pattern would be the Service Oriented Architecture (SOA). Built on that, a modern approach would be to have an MVC (or flavor) on your server, only to expose a service you can work with. On the client side there would be an other MVC styled application, for example an HTML5 and JavaScript powered web application (Twitter or Linked In for example). The client application would use your server side service (the "View" of the server) as its Model. IMHO, this would be state of the art and will probably push server side only MVC aside.

I'm personally looking into implementing something that uses the idea of Resource Methods Representation, though at this stage it's mostly just an experiment more than anything else. It does have some compelling points in that it models a HTTP request/response better than MVC (which is meant for long-lived applications running on a single computer as opposed to short-lived request/response sessions). However, it does have the drawback that if you put methods in your resources for handling GET, POST, PUT, DELETE, etc, then your resources become coupled to the front end. I'm thinking I'm going to separate that out into another layer.