Wednesday, August 25, 2010

Symfony and MVC - follow up

My previous post caused a little bit of confusion so I decided to write this short follow up before I find some more time to provide you with an example explaining my approach. In this post I'll clarify some of my previous statements about separating your models from ORM generated classes.

First off - my approach is not dedicated for everyone. I'm a pragmatist and I follow the rule "don't do more than you have to". Using my approach makes sense only if you work on a big, continous projects. If your project is small or it's the "create and forget" type of project - don't even bother implementing it. You'll end up writing code which you will never make a real use of. Only in projects which really have to be scalable (continous projects or plugins) making more effort at some stages of coding will help you,or someone using your code, save time and energy later.

Second. My approach is not dictated by need of following stiff rules of MVC. What I wrote is a result of lessons me and my team learned during 3 years long work on continous project. I had made the mistakes I described and I know how painful they can be. Simple example of pain that mixing the Model and DAL can cause - try to switch ORMs in your project. If you kept your business logic in DAL classes you for sure have ORM queries in your actions. So switching ORMs means rewriting actions and models. It sucks, doesn't it?

Third. As it has been noted in one of the comments: the misconception I've described doesn't depend on the framework. It can be done in any framework, not only symfony. PHP gives people a lot of freedom in coding and no framework can do anything about it. The only objection I have toward symfony is the ORM generated classes naming. That simply makes a wrong suggestion to new users. Not following the rules in coding is acceptable only if it is made consciously.

Design example will be provided when I find some more time to prepare it ;)

No comments:

Post a Comment