Question

What’s the plus side of annotations for entity description in Doctrine2?

In Doctrine1 & Propel (which I’ve used many times), reverse-engineering a database to create yml or xml, then generating the model is a very quick workflow.

In Doctrine2, choosing annotations, one must write a large amount of boiler plate code just to get the entities in place..; yet annotations seem to be the ‘way to go’.

What am I missing?

Answer 1

The workflow you describe from D1 and propel is exactly the opposite of the preferred way of thinking for Doctrine2. In fact, I avoided writing my own database definitions in D1 as well, for mostly the same reasons I give here:

In Doctrine 2, you are concerned first-and-foremost with your entities. Entities are just plain PHP object, and doctrine just handles your persistence. The fact that Doctrine is there behind the scenes squirreling data away in some database is an practically an afterthought. All of that mess is exactly what you’re supposed to be abstracting away! In theory, you could get rid of doctrine at some future date, and write your own persistence logic. Your entities would still work just like they always have.

Looking at it that way, starting with a database schema is downright silly. You’re more interested in your entities and the business logic embedded in and around them. That’s tasty soup!

Now, since you’re using doctrine for persistence of your entities, it (probably) makes sense to keep your mapping data right there with the class definitions.

So your new workflow is:

1. Design some entities by defining some plain-vanilla PHP classes.
2. Mark the class definitions up with some fancy comments for doctrine
   to chew on.
3. ./doctrine orm:schema:create and let doctrine worry about the
   database table definitions.

Now, if you have some legacy database, things get trickier and a lot less fun. I’ve not really dealt with that scenario with D2, but I imagine it’s ugly.

Regarding Boilerplate code: I see people complain about having to write getters/setters for their entities. I do something similar what this guy does – all my entities extend an AbstractEntity class which uses magic methods to generate getters/setters for any properties that don’t have hand-crafted ones. Once you do that, there’s practically no boiler-plate to be had.

Alternatively, there are plenty of tools these days that will stamp out the boilerplate for you (PHPStorm does this, plugins for Sublime, etc). This makes the boiler-plate fairly painless, and comes with the additional advantage that you can add type-hints, and your editor can provide useful auto-completion.