我已经完成了 Zend 2 的教程，对 Zend\Db 组件感到有些失望。实际上，它无法处理外键（作为内置）。
如何为现实世界的项目（至少十个不同的表和关系）解决这个问题？
我应该考虑或多或少地尝试重写 Zend_Db (ZF1) 的 findDependentRowset 或 findParentRow 吗？如果我认为这是不可能的，我是不是错了，因为它会打破 PHP 对象的教条，不知道使用 Data Mapper 模式出售的外部世界。
我是否应该始终认为使用外键/关系的代码与表示实体的对象无关？这最终可能会变成一个漂亮的意大利面条代码。
我应该为 Doctrine 还是 Propel 放弃 Zend\Db？
这是一个自以为是的问题，因此很快就会关闭。最终Doctrine2（或Propel）只是做同样的事情，你也可以用Zend\Dband手动做HydrationStrategies。
问题是，Zend\Db所有内容都内置于创建您自己的Doctrine2. 您可以做完全相同的事情，但Zend\Db不能被视为成熟的DBAL。该Zend\Db组件旨在处理数据库查询。此外，TableGateway还提供了一些可以使用的东西。
但是，如果您希望Zend\Db成为 DBAL，那么您就大错特错了。Zend\Db已经从所有 DBAL 的东西中减轻了，因为那里有更好的解决方案。你提到的这两个首先会浮现在脑海中。即使在 ZF1 中，Zend_Db-Components 也无法匹配真正的 DBAL 可以做的事情，因此在 ZF2 的设计过程中决定点亮 -Component Zend\Db。现在它对简单的事情很有用，你也可以用HydrationStrategies它来做“ForeingKeyToObject”-Mappings，但它需要一些工作。如果你想要一个更简单的解决方案，我会投票支持DoctrineModule和DoctrineORMModule