你对doctrine有什么经验？我不太喜欢ORM，通常只使用基本的db抽象层，例如adodb。
但我理解所有概念和好处。所以当需要ORM的项目出现时，我想试试其中一个ORM框架。
我必须在doctrine和propel之间做出决定，所以我选择了doctrine，因为我不想处理phing要求。
我不知道我做错了什么。我以正确的心态进入。而且我绝不是“初级”php小子。但我一直在与系统作斗争。有很多文档，但感觉都有点杂乱。像YAML到db表创建这样的简单东西就无法工作，甚至没有错误或任何提示。许多其他东西需要调整才能正常工作。
也许我在这里犯了一些愚蠢的新手假设，一旦我找出来它是什么，我就会有“啊哈”时刻。但现在我完全讨厌这个系统。
是否有人可以给出一些提示，或者指向有关此主题的良好资源，或者一些权威的网站/人士？或者只是推荐另一个ORM框架，可以“只需工作”？
我有复杂的感受。我只是因为SQL非常容易验证而成为了SQL方面的专家。你可以快速测试SELECT语句，直到得到正确的结果。而且重构也很简单。
在Doctrine或任何ORM中，抽象层次如此之多，以至于几乎看起来像强迫症（OCD）。在我的最新项目中，我尝试使用Doctrine时遇到了几个难题。花了我好几天时间才找到一个解决方案，而这是我知道在SQL中只需要几分钟就能写出来的东西。真是太令人沮丧了。
我有些不满。SQL社区非常庞大，但Doctrine的社区/支持却微不足道。当然，你可以查看源代码并尝试弄清楚...那些问题需要花费数天时间才能解决。
底线是：如果没有计划长时间自学，请勿尝试使用Doctrine或任何ORM。
SELECT 转换为您的 DomainObject；自动生成模式并进行验证。 - DennisPropel和Doctrine使用PDO。PDO在Oracle数据库中存在许多未解决的bug，所有这些bug都与CLOB字段有关。如果您正在使用Oracle，请在开始新项目之前请注意此问题。这些bug已经存在多年了。当使用Oracle和CLOBs时，Doctrine和PDO会崩溃。
我的经验与你类似。我刚开始使用Doctrine，从未使用过Propel。然而，我对Doctrine非常失望。它的文档很糟糕。组织不良，相当不完整。
在2015年使用Doctrine 2.5。一切看起来都很顺利，直到我想要使用两个实体（在JOIN中）。[现在掌握了DQL之后情况更好了]
好处：
可以接受的部分：
不足之处：
我认为这个工具在概念上非常棒，但是要适当地执行它需要开发人员花费很多时间。我想用它来生成实体SQL，但然后再使用PDO进行实际输入/输出。只是因为我还没有学会如何使用SQL进行外键和引用完整性。但是，学习这些似乎比学习Doctrine的内部细节要容易得多，即使只是像实体等效于JOIN这样的简单内容。
现有项目中的Doctrine
我（刚开始）使用Doctrine开发现有项目上的新功能。因此，不是为该功能添加新的mysql表格，而是添加实体（使用Doctrine模式生成创建了表格）。在我更好地了解它之前，我保留了不使用Doctrine的现有表格的选项。
如果我要在现有表格上使用它，我将首先……清理表格，包括：
doctrine orm:validate-schema）这是因为Doctrine对您的表格做出了某些假设。并且因为您本质上将通过代码来驱动您的表格。因此，您的代码和表格必须尽可能地达成1:1的协议。因此，一般情况下，Doctrine不适用于任何“自由形式”的表格。
但在一些情况下，只有一些小细节不被考虑，比如你的实体中可能会存在额外的列（我认为除非你要求它，否则Doctrine不会进行检查）。因此，你必须构造查询语句时需要知道自己能够做什么。例如，当你请求一个“实体”时，Doctrine会按照列名具体请求实体的所有字段。如果你的实际数据库架构包含更多的列名，我认为Doctrine也不会介意（我已经通过在我的架构中创建额外的列进行验证）。SELECT i, p
FROM \Entity\Item i
JOIN i.product p
WHERE ...
Item和Product。它们通过Item.product_id连接到Product.id，而Product包含我们想要与Item一起显示的Product.model。//SELECT i, p
$ret[0]->getProduct()->getModel();
//SELECT i as item, p as product
$ret[0]['item']->getProduct()->getModel();
//SELECT i as item, p.model as model
$ret[0]['model'];
flush时，Doctrine会处理这些内容。 - Dennismysqli并为其编写了自己的包装器。 - DennisActive Record 是 Laravel 和许多其他框架所喜欢的东西。它可能非常适合简单的应用程序，并且可以为琐碎的 DB 管理节省时间。然而，从面向对象编程的角度来看，它是一个纯粹的反模式。关注点分离（SoC）被破坏了。它在模型属性和 SQL 列名之间创建了耦合。对于扩展和未来的更新来说是可怕的。
$product->save() 这样的方法就不好。模型处理数据，它不应该关心将任何内容保存到 DB 中。这是非常紧密的耦合。如果我们花时间构建映射器，那么为什么不使用 $mapper->save($product)。根据定义，应该是映射器知道如何保存数据。$model适用于以下示例。$modelMap。$modelMapper->store($model)即可。