[thelist] MVC, Frameworks, and the big picture

[sbeam]

On Sunday 27 July 2008 21:27, Jeremy Weiss wrote:
> Is this
> pattern really so great that there's no downside to it other than the
> learning curve?  I mean, should all my PHP apps from here on out be coded
> according to MVC or are there times when it's better to just do it the
> 'normal' way (procedural). And, if there is room for both methods, how do
> you determine when a project calls for one or the other method?

If the framework you are using is just making your life harder, then don't use 
it. There is a lot of hype behind "MVC" - which is really a vague concept 
that has a lot of implementations of varying quality - so don't get too 
caught up. For you, it might seem like it is solving problems that you don't 
have. If somebody says "MVC is l33t and is best-practice nowadays and blah 
blah" they are full of it. The point is to solve YOUR problem and make that 
time from idea to reality as short and enjoyable as possible.

That said, at some point I think there is a type of parallel evolution that 
happens, where eventually you will find that the pattern, and all the tools 
that tend to come with it, makes a lot of sense for web applications. Plus if 
you get on board with a framework, then you have an advantage in maintenance 
and code-reuse, since you have not re-invented a wheel and other team members 
can benefit from the documentation and community around it. Yes, there are 
problems that the developers of the framework have solved that you might not 
have, but maybe you will have them soon. So even if you don't 100% see 
eye-to-eye with it all, that is still a plus.

I just so happened across this blog post on zend devzone today, which 
basically expands on these points.
http://pookey.co.uk/blog/archives/56-Should-you-learn-a-framework.html

enjoy
Sam