Advantages of using Doctrine for PHP?

Question

Just came across the Doctrine Project which has an Object Relational Mapper and a DB Abstraction Layer. What does Doctrine provide that other PHP abstraction layers don't? And what practical use can you put the ORM to, apart from fetching objects via queries written in Doctrine Query Language? Is the query language really something you want to develop an entire web app in? Does it perform well?

On the whole does building an app on Doctrine make it easier to maintain and understand? Is it over-engineered, and is building on an abstraction layer sensible for small-medium size projects? (<50 GUI screens), as opposed to directly working with MySQL.

Fluorine

Answer 1

What does Doctrine provide that other PHP abstraction layers don't?

1. Implements DataMapper pattern rather ActiveRecord.
2. Supports annotations, XML and YAML for schema.
3. Uses DQL.
4. Uses benefits of PHP 5.3+.
5. Is fast and has large community.
6. Except ORM there is ODM.

Is the query language really something you want to develop an entire web app in?

Just a part of the application responsible for maintaining business-objects should be aware of the existence of Doctrine. And that part doesn't have to be 100% Doctrine-based.

On the whole does building an app on Doctrine make it easier to maintain and understand?

Definitely. The code is easier to read, understand and maintain.

Is it over-engineered, and is it sensible for small-medium size projects?

Actually Doctrine is quite simple in its fundamentals. And it's a very good choice for small, medium and even some large applications.

---

Doctrine isn't the answer for everything and sometimes it's a little problematic. However for typical tasks it's extremely useful. IMHO the best ORM/ODM for PHP at this moment.

Jinja

Answer 2

I'd like to add a few points to Crozin's answer, but unfortunately can't comment it. Here they are:

• Doctrine does not use magic methods __get() and __set() to access entity attributes, all the entity attributes should have getter / setter. This improves IDE code completion and you do not need to look at DB table structure all the time.
• Doctrine completely abstracts you from real table field names. Once you mapped entity properties to DB fields - you use property names everywhere. Same for table names.
• Doctrine uses repository pattern which hides the details of obtaining entities.
• Doctrine utilizes "code first" approach, so you can create entities first and then generate database for them automatically. Reverse case is also possible.
• Doctrine has powerful query builder, so you can utilize builder pattern for queries with conditional parts.
• Doctrine uses foreign keys and constraints to perform cascade actions and keep data consistent.
• Doctrine's UnitOfWork is a pretty great and smart thing, which has no analogue in other php ORMs

IMHO at the moment doctrine provides best IDE code completion support and DB layer abstraction among all php ORMs available. It is not over-engineered and follows SOLID principles.

Olivann

Answer 3

I'd like to add a point to GerKirill's answer. The absence of support for magic getter/setter methods is a weakness, IMHO, not a strength. If you've ever scrolled through dozens of pages of identical getters/setters, you will realize that these methods are a huge waste of space (not to mention compile time). No-one accidentally sets an object variable, and a setter does not prevent you from doing that ... when you want to change the property, you just call the setter (how does a setter "protect" the property -- if you are going to make a typo and directly set the wrong property value, you will make the same typo and call the wrong setter). And it is very rare for a setter or getter to do anything other than get or set a property. If you have to do something special to set or get a property, that property should be a method (see http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html), or you should be refactoring your code, or you should be calling a property validation function (generally at the time the object is created). This is one of those un-challenged truisms that plague the OO world. Think about it before you post the standard received-wisdom reply.

Shantae