11

I know that some users use Doctrine 2 instead of Zend_Db in Zend Framework. But I don't know why. Why is Doctrine2 better than Zend_Db and why Zend_Db is not good?

Thanks

adlawson
  • 6,303
  • 1
  • 35
  • 46
user594791
  • 617
  • 1
  • 8
  • 15

3 Answers3

25

(7-Mar-2013) Disclaimer: This answer is probably now a bit out of date. I'm not keeping up with the PHP community at the moment and this comparison is between Doctrine ORM v2 and Zend Framework v1. This is an apples vs. oranges comparison because they're two different things.

Out-of-the-box Zend_Db is more just an enhanced Database Abstraction Layer on top of PDO, where as Doctrine 2 is a Object Relational Mapper (which sits on top of it's own DBAL).

Doctrine 2 is much better for more complicated domain layers, because all your business logic, persistence logic, etc are separated over multiple classes, so they don't serve multiple roles. Also, because you have more classes - that are cleaner and loosely-coupled - it makes testing them much easier.

Futhermore, you'll be writing only fraction of the SQL that you be using Zend_Db, because you can manipulate your entity objects and Doctrine translates those change to the database. The generated SQL also takes advantage of transactions which gives you a decent performance gain!

I'd recommend you read up on Domain-Driven Design to get a better understanding of why Doctrine 2 is so awesome.

Don't get me wrong though, you can do DDD with Zend_Db but it's not really there OOTB (because it's not an ORM), and wouldn't be nearly as powerful and full-featured like Doctrine 2.

Cobby
  • 5,273
  • 4
  • 28
  • 41
  • 1
    Agreed. Zend_Db is a mess for any middle or large project. While in Doctrine you have one repository for each entity, with Zend_Db you will end up extending Zend_Db_Table, which use the Table Data Gateway pattern, and including methods like getAllAllowedUsers() with customs SQL joining several tables and resulting in a Zend_Db_Table_Row that actually doesn't has nothing with your actual business model. So you merge Zend_Db_Table with the Repository pattern. Maybe you realize that you actually need a Data Mapper, so you start creating your own implementation, reinventing the wheel. – Keyne Viana Feb 18 '12 at 03:47
  • Or even worst: Some developers create the selects on the controller itself. `listAction() { `$UsersTable->select()`...` – Keyne Viana Feb 18 '12 at 03:49
  • I know this is an old question, but in 2 years of doctrine 2 +zend framework experince I would not absolutely recommend using doctrine 2 IT IS SLOW very SLOW, it is not good for web application, it has great abstraction but have also big drawbacks. – albanx Jul 25 '12 at 17:06
  • 1
    Care to elaborate on the specifics on how Doctrine was slow for you? – Cobby Jul 27 '12 at 04:23
  • +1 for the excellent argument for D2. I am still in favour of Zend_Db as the set-up cost is greatly reduced (it has taken me half a day to set up and tweak a handful of tables usind D2). @KeyneON notes that you need to use custom SQL to join several tables for a row object you cannot update. This is no longer accurate as you can declare tables relationships in the model classes (http://framework.zend.com/manual/1.12/en/zend.db.table.relationships.html) which does the same things as D2 does regarding fetching dependent data in separate tables. What I will say in D2's favour is that the function – Richard Parnaby-King Mar 06 '13 at 16:58
  • calls for fetching the foreign data is easier than what is required in the ZDb classes, however there is no reason why these calls cannot be wrapped in a simple function call in the table class, i.e. in your class have a function that returns the foreign data instead of making the complex function calls time and again everywhere in your code. – Richard Parnaby-King Mar 06 '13 at 17:02
0

If you have a small project wich is bound to use a specific DBMS, you do not need ORM and Doctrine.

If you have a project wich is large and in the future might need adapters to switch from one dbms to another, than you might consider using Doctrine

As you can read in the Doctrine description:

Doctrine 2 is an object-relational mapper (ORM) for PHP 5.3.0+ that provides transparent persistence for PHP objects. It sits on top of a powerful database abstraction layer (DBAL). Object-Relational Mappers primary task is the transparent translation between (PHP) objects and relational database rows.

Al-Punk
  • 3,531
  • 6
  • 38
  • 56
  • 1
    please define "large" :-) Thanks – opHASnoNAME Feb 02 '11 at 13:57
  • 1
    Your answer implies that the primary benefit of an ORM is DBMS portability. But plain PDO - or really any DBAL - provides that. I find the real benefit of an ORM is the clean distinction between the models themselves and their persistence/hydration to/from a repository. – David Weinraub Jul 09 '11 at 17:18
0

Zend_DB and Doctrine uses different ways. Zend_DB works like table data gateway and row data gateway. Doctrine is object mapper.

In my experiences Zend_DB enough and fast for most common tasks. Doctrine is slow and uses more memory than Zend_DB.

Matt
  • 5,478
  • 9
  • 56
  • 95
osm
  • 4,186
  • 3
  • 23
  • 24
  • In my experience it's harder to maintain a code that doesn't have a clean separation between business logic and data access layer. You tend to use Active Record alike patterns when dealing with your model. For instance, extending Zend_Db_Table_Row and Zend_Db_Table or even creating your own data mappers and repositories (Repository pattern). It's definitely for small projects and teams, I think. – Keyne Viana Feb 18 '12 at 03:40