Why Propel is bad

There’s always the need to abstract out our data persistence mechanisms so that we don’t have to mess with mapping user data to tables by hand and handling the relations between user data entities.

I’ve been always using Doctrine ORM in my Symfony 2 projects. But at some moment I’ve been forced into using Propel 1.7, as it’s a corporate standard.

And oh my god, it’s just a load of crap. See for yourself:

• The model code is automatically generated from a schema, which means that you cannot ever be sure that your schema changes won’t break the model interface.
• The schema.xml format is counterintuitive, you have to dig through the docs most of the times you want to change something there.
• You cannot import different schemas during DI container compilation. This means that a schema cannot be modified depending on your bundle’s configuration.

What’s the worst of it all is that Propel is not container-aware at all. It supposes that you’ll create new instances of your models and queries with factory method calls from your service layer or in your controller.

This leads to some serious consequences. You can never tell whether a service (or a controller defined as a service) talks to the DB. Propel just ignores the container and sits aside.

Having a static method-based ORM also leads to untestable code; it’s not an easy task to mock dependencies satisfied via new instance creation or named constructors (these are the two ways to create a Query or a Model in Propel).

If you want to assure that the separation of concerns principle is not violated, you just cannot have an ORM that allows you to deal with data persistence literally anywhere in your PHP code.
So, if you’re going to develop a custom bundle for Symfony, please, don’t use Propel!