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:

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!


Now read this

Symfony events and persistence

Despite the fact that ORMs are quite evil, often we cannot escape this burden because the decision about using or not using an ORM was taken by someone else on the team, maybe way before we could affect this decision somehow. Well, ORMs... Continue →