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!

 
21
Kudos
 
21
Kudos

Now read this

Know your components: A simple serializer with Symfony’s property access

Recetly, I needed to implement a quite simple serializer that would be used to prepare the entities from the database for indexing in ElasticSearch. I didn’t really need to get JSON or XML out of it, I only needed to transform my objects... Continue →