0

I've completed the tutorial of Zend 2 and feel a bit disappointed by the Zend\Db component. Indeed, it's not able to handle foreign keys (as a built in).

How to approach this problem for a real world project (at lease ten different tables and relationships)?

Should I consider to try more or less to rewrite the findDependentRowset or findParentRow of Zend_Db (ZF1)? Am I wrong if I think this is impossible because it would be breaking the dogma of the PHP object ignorant of the outside world sold with the Data Mapper pattern.

Should I always consider that the code using foreign keys/relationship have nothing to do in the objects representing entities? This could end up into a beautiful spaghetti code.

Should I drop Zend\Db for Doctrine or Propel?

AsTeR
  • 7,247
  • 14
  • 60
  • 99

1 Answers1

5

This is an opinionated question and therefore will be closed pretty soon. Ultimately Doctrine2 (or Propel) just do the same thing, that you could do manually with Zend\Db and HydrationStrategies, too.

The thing is, Zend\Db has everything built in to create your own Doctrine2. You can do exactly the same kind of things, but Zend\Db is not to be seen as a full fledged DBAL. The Zend\Db Component is meant to be handling Database-Queries. Furthermore a couple of things like TableGateway are given that one can use.

However if you expect for Zend\Db to BE a DBAL, then you're simply mistaken. Zend\Db has been lightened up from all the DBAL stuff, because there are better solutions out there. The two you've mentioned would come to mind at first. Even in ZF1, the Zend_Db-Components have never been able to match what a real DBAL could do and therefore the decision has been made during the design of ZF2 to light up the Zend\Db-Component. Now it's failry useful for easy things and you can use HydrationStrategies to do "ForeingKeyToObject"-Mappings, too, but it requires a bit of work. If you want an easier solution my vote would go for the DoctrineModule and DoctrineORMModule

Sam
  • 16,435
  • 6
  • 55
  • 89