1

Can you list pluses and minuses native ORM opposite Doctrine?

ZF1 had very proger-fiendly native ORM for me (Zend_Db_Table and Zend_Db_Table_Row), Zend\Db\TableGateway\TableGateway and Zend\Db\RowGateway\RowGateway is continue of this. Why most people try to use Doctrine2, despite it's bulky, primary reason?

P.S. Even word "repository" not associates with databases for me ..

Alexander Goncharov
  • 1,572
  • 17
  • 20
  • 1
    You can't really compare then as both ZF1 and ZF2 implement database abstractions using the Adapter and Row Table Gateway Patterns that you are familiar with. They do **not** however offer an object relational mapper (ORM), like Doctrine 2. – AlexP Jun 27 '16 at 22:20
  • But last sample, described here http://framework.zend.com/manual/current/en/modules/zend.db.table-gateway.html - gets set of active records . We can manualy put Set class in TableGateway , we can manipulate ActiveRecord class . We can choose adapter to select set. Why this is not ORM ? – Alexander Goncharov Jun 27 '16 at 22:48
  • If you want to use `Entities` better choice is Doctrine. Otherwise you need create/write something to work with `Entity` dependencies. And of course a lot of code with TableGateway. – newage Jun 28 '16 at 09:54

1 Answers1

0

Let's start with a couple of definitions.

Database Abstraction Layer (DBAL) : A layer that sits on top of a database connection (Driver + Platform) and offers an intuitive and flexible API for communicating with most popular relational databases.

Object-Relational Mapping (ORM) : A technique that lets you query and manipulate data from a database using an object-oriented paradigm. This paradigm must include a Unit of Work to keep track of the state of your Entities (data objects) in order to know what operations (like hydration and database transactions) will have to be performed to maintain and assure the accuracy and consistency of data over its entire life-cycle. Also, the paradigm must take into account object relations in order to preserve data integrity. These elements are the essential aspects of any ORM implementation.

Thus, Zend\Db does not offer ORM capabilities since it is only an Abstraction Layer. You could try to build one by using hydrators and a Zend\Db\ResultSet\HydratingResultSet, and then, by creating your own Unit of Work. I have already seen code created by Ralph Schindler that was going down this road (the code was quite impressive, by the way!) but was still not an ORM per se. So, if you decide to go down the same road, you will have your work cut out for you... Using Doctrine's ORM would definitely be much simpler!

Finally, Zend\Db\TableGateway\TableGateway and Zend\Db\RowGateway\RowGateway were designed using known Software Patterns (TableGateway Pattern and Active Record Pattern, respectively - not to be confused with Design Patterns). But this has nothing to do with Patterns of Enterprise Application Architecture (EAA) as such (like the Unit of Work Pattern). For more information on EAA Patterns, please read Martin Fowler's book Patterns of Enterprise Application Architecture.

Andrew C.
  • 36
  • 3