Apr 20, 2014
There are lots of bundles for Symfony. Some of them are infrastructural while others go too far and affect the domain and database schema for them to work properly. I use only infrastructural bundles and suggest you do the same.
Infrastructural bundles are the ones that affect the infrustructure of your app but not its domain and database schema.
There are lots and lots of infrastructural bundles out there and this list is in no way complete. It’s here just to give you an idea of what infrastructural bundles are.
Symfony itself does not impose anything on domain and database schema. Actually, Symfony doesn’t say anything about model at all. Hence it’s infrastructural too. You can develop your domain and then add Symfony on top of it to manipulate it.
Compare this to other frameworks out there that enforce some structure on domain classes and database schemas. For example, they force you to extend some classes and to have an autoincrement
id column in each table even if you don’t need it.
CMSes enforce even more stuff. Usually, you don’t have any control over domain and database schema with CMSes. All you can do is extend them by plugins but then again you often have to obey the rules. CMSes let you start fast but when you need something custom and flexible, you waste more time fighting a CMS than adding functionality.
Here are examples of interfering bundles:
Basically, almost any bundle that has some kind of model/entity/document classes and corresponding mapping metadata does too much and interferes with domain and database schema.
Let’s take a look at
FOSUserBundle. Amongh other things, it forces you to use groups and to serialize the
roles array before storing it in the database. That ties your DB to PHP and that is a bad idea.
Maybe it allows you to override that, but then you’ll have to override some other parts of the bundle that depend on that. And then some other parts that depend on the ones you just overrode. And then you run into the same problems you run with CMSes: you start fast but then have to fight it to get exactly what you want. Why waste time on this fight? Why not just create your own flexible user/security system?
For some reason you’ve chosen to use a framework rather than a CMS for a project. I don’t know what was your motivation for that but my motivation is flexibility.
I don’t use a framework for each project I work on. I strive to use the right tool for the job and when I don’t need flexibility, I use a CMS like Drupal or a static site generator like Jekyll. Frameworks are not a silver bullet.
Now, given I’ve chosen to go with a framework for flexibility, why would I give up some of that flexibility by using a bundle that enforces particular domain and database schema? It doesn’t make sense.
A lot of people motivate this by rapid development. As if using, say
FOSUserBundle, they save a lot of time of development. I don’t know what is the size of projects those people work on, but the projects I usually work on span from 6 months to several years. Spending a day or two on developing a custom and flexible user/security system that behaves exactly as I need it to is not a big deal.
Of course, if you’re churning out a project after project every one to four weeks, a day or two might be a big deal. But if you’re developing projects that small, why bother using a framework in the first place? You could as well use a CMS. Or a CMF.
Use only infrastructural bundles and avoid bundles interfering with domain and database schema.
If you’re a fan of RAD, maybe you’ve chosen the wrong tool for the job. Maybe you need a CMS or a CMF but not a framework.