MVC or not MVC

[a_bertrand]

Some people seems to think that you should always use MVC in any project. I'm somewhat more moderated toward it. Let's try to discuss it, and no it is not related to my engine ;)

First of all what is MVC, as I wonder if all those stating MVC is a requirement really understand it well:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

MVC is composed of at least 3 distinct pieces which should also implemented in at least 3 different classes:

- A model (which is basically a storage or a memory representation of your data (an array key / value pair is not enough usually))

- A controller which let you do actions on the model, for example edit some data

- A viewer which reads the data from the model and prepare or generate the GUI for the user to work with.

On the view side you could even use a template engine on top of it, so that would be again split in 2 parts. What is important to note is that the 3 are loosely linked together, which means that you should and must be able to work only on one of them at a time, while working with pseudo versions of the others for example to test the different pieces of software.

MVC is a design pattern, which is not dependent of the language, tools or where you will use it. A design pattern is like a general idea that can be reused, not really a cook list but just a general idea of what could be done to solve a given problem.

Where this design pattern is useful:

- It let you test the pieces of your software in separated ways, for example it's quiet doable to test a model and a controller, while the view which is related to a GUI usually can be more tricky to test in an automated way. So where you need to have automatic tests running for example in big software houses, or in fields where even a small bug can have huge effects (for example medical field), automatic testing is a must. (Unit testing is part of that for example)

- When you may offer more than one interface to the same data, for example a web interface and a standalone GUI, and maybe even a mobile GUI, an MVC will help as you will re-use 2 of the 3 parts. Actually, you may even run the view on one server while the model and the controller may run on another one.

When is this design pattern overkill:

- Here it's question of taste and personal opinion. If you just do a small guest book for you personal site maybe it's not really useful. Again personal opinion.

Ruby on rail works basically on MVC as well as many PHP framework offer some form (some times very good one) of MVC to use. So no you don't need to start from scratch yourself most of the time.

Personally, I would use it only if I have a requierment for it, as it has an overhead in term of work to invest, specially if you don't use some good framework. And unless I need / implement unit tests, system tests, integration tests... or I need multiple "views" of the same content, I hardly see a benefit from it. But again, personal opinion. I'm more of the KISS principle (Keep It Simple Stupid) where small code means less chances of bugs.

So what's your opinion about it and where do you use it if you do, or why don't you use it if you don't ?

[BlackScorp]

Well, many ppls speaking about MVC but MVC does not work in PHP since PHP Code has no state. In Most Cases Web Applications are following Front Controller Pattern seperated into Model Views and Controllers.

In my Opinion , if you wish to implement unit tests and other tests. Try to use "Clean Code".

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

With Clean Code you just Create your custom classes outside of any Frameworks. The MVC Frameworks are used as "Detail" which call your classes and display some HTML Code depends on Request.(Delivery Mechanism)

Here a video of Uncle Bob

The key of Clean Code is produce an application independant of Framework,Database,Webserver so anyone would just pick your engine and call your classes/methods in Zend Framework for example, others who prefere Sympfony, would just use em.

Advantage is, you could just use your data structure later as an API for example.

The Hard part would be the Plugins. If you use Clean Code your plugins could have some of Buisness Logic but they also need a delivery mechanism to use the Buisness Logic. so a plugin may needed to be created with other Frameworks as well.

Personally iam using Clean Code with Kohana Framework as Delivery Mechanism and not just MVC but HMVC + MVVM(MVP), which basicly means that Views are Plain Old PHP Objects which are rendered by a Template engine.

I User http://behat.org/ for describe Features and create unit tests. Basicly just simple classes filled with sample Data, once feature is complete and tests are passed i implement it in Controllers.

http://zombor.github.com/ a good Tutorial for it.

Hope it helps to understand that MVC doesnt matter

[a_bertrand]

MVC is not a standard, it's just a design pattern don't mix the 2. It's like saying that you can always use eggs in any receipt, that would be wrong. Don't take it badly it doesn't mean MVC is not good, simply it's not a "fit always" solution. On the other side, OO programming could always fit.

BTW The controller SHOULD NOT display, it's the back from the view. That means it receive the interactions from the user. And... No you should not implement the logic of the actions on the model as it would be wrong again.

Also, indeed when I made the PHP certification it was still PHP 4, but guess what, MVC is MUCH older than this ;)

[BlackScorp]

as i told. if you would start from the Scratch, then just seperated the Buisness logic. So programmer which dont use MVC can still call in their login.php following code

require_once 'path/to/mccodes/init.php';
class Mysql_Account_Repository extends Account_Repository{
public function create(array $data){
//insert into code
}
}
$repository = new Mysql_Account_Repository();
$login = new Account_Login($repository);
if($login->execute()){
//redirect
}else{
//show error
}

 

if you implemented PSR-0 autoloading, so it is even easier to use your Buisness Logic in Frameworks like Zend/Symfony/Lavarel/Kohana etc.

dont think about MVC or Not, think about to create kind of API which can be implemented in simple php files or complex MVC Frameworks.

just my 2cent

EDIT: @k1ngscorp1o

Well a usual MVC Application in PHP has more than Model,View,Controller. There is also a Request, Response and Route classes. a Controller does not display stuffs it pass data from Model to view or from Request to Model and controller pass the view to Response classes, so the response do the output, the controller just trigger it.

and if MVC would be a "fit always" solution, why there exesists other Pattern for Webapplications like

MVVM (http://en.wikipedia.org/wiki/Model_View_ViewModel)

MVP (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter)

HMVC (http://en.wikipedia.org/wiki/Hierarchical_model%E2%80%93view%E2%80%93controller)

Edited April 2, 2013 by BlackScorp

[a_bertrand]

Ideally the controller should not have anything to do with the view, otherwise forget any dependency injection.... or make things harder. Ideally, when the model updates, the view is "triggered" or waked up because the view is an observer of the model. Yet, don't know how each PHP frameworks handle those, pretty much safe that it's hardly doable as all the "event" model which would be involved is somewhat missing in PHP.

SO when you say the controller does the view (directly or not) it's wrong and you would end up with a different design pattern than the MVC. Nothing pointy or technical discussion here, it's really what MVC is, 3 different and distinct objects which talk to each others, each of which is in charge of a particular process. Check back the wiki link I added at first, it gives exactly the definition of the MVC pattern. Yet if in the framework you use it's not like that, then it's an issue of the framework which doesn't implement a true MVC but something... different. Bad? no, simply different.

[BlackScorp]

@BlackScorp - sorry but you were no longer taken serious the second I saw mccodes in your example LMFAO

this was just an example, i thought a_bertrand is speaking about rewriting mccodes or were my thoughts wrong?

the links i posted are no alternatives, you can see them as "extensions" for MVC, since MVC does not cover all needed things in webapplication because so many technologies are combined. you can use HTML output as view, you can also create json output and pas it to a flash/silverlight/pure JS application. you can handle requests by PHP or you can handle requests by Apache and .htaccess or you can even mix it. You can use Models as mysql DB, you can also create a Model which is using an oAuth API to store or get data from another server. you can even save data on local storages and use JavaScript as Model. MVC cannot describe all posibilities nor you can see it as standard. You could describe it as "Best Practice"

Edited April 2, 2013 by BlackScorp

[a_bertrand]

Ok let's skip this difference (which for me is not so small), now imagine I want to make a 3D renderer, or a sound synth.... Is MVC the correct pattern? no. Same applies on any website. Are all the website the same? From google, to a webshop, to the embeded webserver you may find on your ADSL router. Have all those the same requirements? No, not really. Sure they do all have to generate some data your browser will understand (being html, flash or whatever else). So why would one pattern always find it's way?

Now if you talk about what people talk today as web development (specially with PHP), sure you will hear about frameworks, MVC, and maybe some jQuery or other integration. It tends to be a bit over used in my opinion, where people starts to miss what exactly is the goal of this design pattern.

And for sure BlackScorp I wasn't talking about rewriting McCodes. I'm not the owner of that script, not I'm in any mean interested in it. It was just a friendly discussion about who and why use MVC.

[BlackScorp]

And for sure BlackScorp I wasn't talking about rewriting McCodes. I'm not the owner of that script, not I'm in any mean interested in it. It was just a friendly discussion about who and why use MVC.

sorry misunderstood you, thought because youre administrator of this forum, so youre owner of this mccodes(which has many topics here in forums).. well i ok then. anyways using MVC and another Designer Pattern would be a good way, but youre also able to make many things wrong in MVC. Currently i had more disadvantages on pure php scripts than in MVC applications. personally i used it even for a one page portfolio because one day an application need more requirements. a bit overhead is ok as long as you have a reusable and maintable code

[Spudinski]

MVC is not applicable everywhere. And I somewhat agree with a_b, it's becoming over-rated, much like Singletons.

Both design patterns are great, but they share a common fate: they are being abused by people who do not understand the problem they attempt to solve.

MVC is just very popular in PHP, but it's because of the fundamentals of the language: it has always needed an abstraction of logic from presentation and the MVC pattern provides this generously.

But this is all very ironic if you read the history of PHP, and what it was initially designed for...

[dnenb]

Do any of you use a mvc-like pattern on your games?

[SRB]

Do any of you use a mvc-like pattern on your games?

I built a game using MVC but never launched.

Well, I say built -- I was 90% into the basic core game before I lost interest.

It ran smooth and fast, but editing took longer due to having the HTML and PHP separate, so you end up flicking through too many folders in FTP to get to PHP files, then navigate the template folder to find the correct directory for the associated file.

[john.]

It ran smooth and fast, but editing took longer due to having the HTML and PHP separate, so you end up flicking through too many folders in FTP to get to PHP files, then navigate the template folder to find the correct directory for the associated file.

Sounds awfully complicated. Why do you even use a remote web server when developing your projects?

 

Modular Gaming is built on Kohana and uses the HMVC pattern.

[SRB]

Sounds awfully complicated. Why do you even use a remote web server when developing your projects?

 

Modular Gaming is built on Kohana and uses the HMVC pattern.

Looks awfully complicated.

Why do I need a thousand files to do the few tasks I require?

[john.]

Looks awfully complicated.

Why do I need a thousand files to do the few tasks I require?

Modular Gaming is built on Kohana and uses the HMVC pattern. was never addressed to you, I think I should have placed a quote in between.