[thelist] MVC, Frameworks, and the big picture
sbeam
sbeam at onsetcorps.net
Tue Jul 29 09:37:40 CDT 2008
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
More information about the thelist
mailing list