MVC approach in PHP Development
 

MVC - Model View and Controller. The most standard approach in application development is MVC according to many peoples consideration. What if it would be implemented in PHP?

Most of the framework in PHP using MVC, then how about the use of MVC in our custom applications?

Lets put up words right here, to get through the sane...

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Personally I like the Model Plane > View from my Patio > BBQ pattern.

What is that?

delayedinsanity haha that sounds like a great model to follow

About a month ago I had never touched anything MVC. My first time looking at it it just seemed like it over complicated everything. I decided to take a closer look and write my own basic little framework and now I understand it very well and really like using it. It might not be appropriate for everything, escpecially very small scripts, but I can definitely see myself using it more from now on.

Using MVC to handle a form is like hitting up Wal-Mart in a Peterbilt.

If you're developing a major application however (delivering the goods to Wally World), then MVC is completely the opposite of over-complication. It's a very solid design pattern, usually being built through the use of other very popular design patterns, which I would presume accounts for a large portion of its popularity.

At the very least, if you plan on developing enterprise level applications, or even just programming (PHP or otherwise) for an extended period of time, it's one of the many patterns that should be learned just to gain the experience from it. The concept alone can turn some on-paper ideas from improbable to highly possible very quickly.

I still prefer BBQing though.

i use codeIgniter and really it simplifies all work incredibly !

MVC is great when used in the appropriate places. It can and will over complicate things if the problem has a relatively simple solution, akin to hammering a panel pin in with a sledgehammer, whilst it will probably do the job its completely unnecessary, when a smaller hammer would do it just fine (and will also minimize the risk of pulverizing the object in which the nail is going into)

I have found MVC to be fabulous in my work on a daily basis on medium to large projects.

I must say, I too prefer to BBQ, grr now i'm hungry again!

I have never used MVC as i have never got how it works.

also what this BBQ?

Basically it's like this:

- Different controllers (or methods in controller classes) represent different pages
- Controllers use models to interact with the database
- Controllers use views to display HTML to the user

It just divides your application into parts based on primary function. Makes it a lot more organized and speeds development.

Not really. They don't need to use models to interact with the database. Otherwise you wouldn't be able to access the database from the controllers. Besides, models can be used for a number of other things, not only database handling.

However, models are most often used to interact with the database. It's just not limited to it.

Now why would you need access to the DB via the controller?

In my mind controllers should not do any form of business logic, all of that is handled via the model, just like views handle presentation logic, so therefore you shouldn't need to access the DB via the controller. Obviously there is a need for a certain amount of logic in controllers, as there is in the view layer (don't get me started on PHP template languages at this stage of the day PLEASE), but to have the controller layer bunged up with logic is just silly, you may as well just go back to the old skool way and have a php file per page.

Models are not synonymous with database. I quite often see code that is supposedly 'MVC' and all I can see in the model is a pointless 'ActiveRecord' (or similar) class with no logic in it and a controller littered with business logic.

Controllers are there to glue the model to the view, interpreting user input into the model and passing data back to the user via the view.

fat model and a thin controller is all you need to remember.

I'll stop myself there as we are wandering dangerously close to the 'off topic' mark and I will being ranting before long.

Now where did I put my coffee?

You should probably have taken your coffee before replying xD
I didn't say you should access the database via the controller. I just said you CAN, and that the use of models isn't limited to database handling.

I "proved" this by saying that otherwise you wouldn't be able to access the database via the controller. Because if models would be limited to database handling, then you should be forced to use models for the database handling, and controllers wouldn't allow you to access the database. But controllers do allow this thus models aren't limited to database handling.

You both make valid points, but keep in mind I was just generalizing for the sake of simplicity. Also remember that there are different variations of MVC, but again, that just makes it all the more complicated for someone trying to learn it at first. :)

Yea, its not a good idea me replying to threads after just comming out of a meeting and a lack of coffee, I'll remember that in the future! I still maintain that the idea of accessing the DB from the controller makes me feel a little edgy, it will end up in a crawling horror of an application!

Indeed! Its probably one of the hardest patterns to learn because it is interpreted by many people in many different ways. The way I do it is the way I found it most useful for my own projects, I found that lumping most of the logic in models made it alot easier for me in a number of ways (reuse, unit testing etc).

I dont even know what MVC stands for haha.