Doctrine2 - 注释 vs yml / xml

Posted 2023-04-12

【中文标题】Doctrine2 - 注释 vs yml / xml

【英文标题】：Doctrine2 - annotations vs yml / xml

【发布时间】：2011-08-09 18:35:06

【问题描述】：

Doctrine2 中实体描述注解的优点是什么？

在 Doctrine1 & Propel（我用过很多次）中，对数据库进行逆向工程以创建 yml 或 xml，然后生成模型是一个非常快速的工作流程。

在 Doctrine2 中，选择注解，必须编写大量样板代码才能使实体到位..；然而注释似乎是“要走的路”。

我错过了什么？

【问题讨论】：

Doctrine2 伟大的原因之一是领域模型不一定要与数据库模型相对应。从这个意义上说，Doctrine 1 更具侵入性，因为它强制您的模型从 Doctrine_Record 继承，而您的存储库则从 Doctrine_Table 继承。如果你使用 Symfony2，你会在生成实体方面获得很多帮助，它还让你可以选择是否要使用 XML、YAML 或 Annotation 映射格式。这使您只需定义实体之间的关系。

我已经感觉到模型实际上与模式本身的耦合要少得多。我以前用过很多 sf，但现在正在增加 ZF，所以目前它是 zf 1.x / Doctrine2 组合。来自 sf2 的额外支持不足为奇。以后我会记住的。

【参考方案1】：

您从 D1 和推进中描述的工作流程与 Doctrine2 的首选思维方式完全相反。事实上，我也避免在 D1 中编写自己的数据库定义，原因与我在这里给出的大致相同：

在教义 2 中，你首先关心的是你的实体。实体只是普通的 php 对象，而学说只是处理你的持久性。事实上，Doctrine 在幕后将数据存储在某些数据库中，这实际上是事后才想到的。所有这些乱七八糟的东西正是你应该抽象出来的！从理论上讲，您可以在将来的某个日期摆脱教条，并编写自己的持久性逻辑。您的实体仍会像往常一样工作。

这样看，从数据库模式开始是非常愚蠢的。您对您的实体以及嵌入其中和周围的业务逻辑更感兴趣。这汤真香！

现在，由于您使用原则来保持实体的持久性，因此（可能）将映射数据与类定义一起保存在那里是有意义的。

所以你的新工作流程是：

通过定义一些普通的 PHP 类来设计一些实体。 用一些花哨的 cmets 标记类定义 咀嚼。 ./doctrine orm:schema:create 让教条担心 数据库表定义。

现在，如果您有一些遗留数据库，事情会变得更棘手，也不会那么有趣。我还没有真正用 D2 处理过这种情况，但我想它很丑。

关于样板代码：我看到人们抱怨必须为他们的实体编写 getter/setter。我做了类似what this guy does 的事情——我所有的实体都扩展了一个 AbstractEntity 类，该类使用魔术方法为任何没有手工制作的属性生成 getter/setter。一旦你这样做了，几乎没有样板。

或者，现在有很多工具可以为您消除样板文件（PHPStorm 可以做到这一点，Sublime 的插件等）。这使得样板文件相当轻松，并带来了额外的优势，您可以添加类型提示，并且您的编辑器可以提供有用的自动完成功能。

【讨论】：

反响很好。我正在适应你在这里概述的新工作流程，但一个缺点，我在这里有点抱怨，是时候开始了。我可以在很短的时间内用 SQL 编写模式、生成 XML/yml 和模型。然后，我立即开始讨论域逻辑。我知道在灵活性方面存在缺陷。我也考虑过你提到的基类，但所有这些魔法有点慢：D 不过，我可能最终会因为时间的缘故而这样做。当我回到代码时，我会仔细研究这个示例基类。

一旦你掌握了窍门，你会发现这是一个相当快速的工作流程。你所有的工作都集中在一个地方，你只需敲击 orm:schema-tool:update --dump-sql（或 --force）。一旦您将各种注释指令提交到内存中，工作就会快速进行。 RE：魔术方法，如果您需要优化，您可以随时返回并手工制作 setter/getter。在大多数情况下，你永远不会。

没错，没错，但是除了（small :)）性能优势之外，将函数实际标记到实体中的另一个好处是在生成的文档中查看方法，例如 doxygen 或 phpDocumentor。不过，我肯定会使用基类来完成编写实体的第一阶段。

确实，魔术方法使生成的文档或 IDE 自动完成功能变得不那么有用。您可以使用 @method 向您的类文档添加注释，这些文档工具和 IDE 将使用哪些文档工具和 IDE（请参阅 manual.phpdoc.org/htmlSmartyConverter/PHP/phpDocumentor/…），但此时您不妨删除无聊的方法。

看来@timdev 发布的链接不再有效。只是想为每个人发布一个更新的链接。 epixa.com/2010/05/the-best-models-are-easy-models.html

【参考方案2】：

我在 yml 或 xml 上使用注释的主要原因是易于配置。我不必查看另一个文件来记住（例如）我在多对多关系中设置的连接表名称。而且，如果我更改了域对象中的某些内容（这在我的开发过程的早期发生了很多），我不必记得也用这些更改来更新另一个配置文件。

但是，正如您所说，数据库架构更容易移植到其他配置格式之一，因此在这种情况下，您可能确实最好使用 yml 或 xml 而不是注释。归根结底，这一切都归结为个人喜好......使用你最喜欢的任何东西。

【讨论】：

我在doctrine-user 上发帖并得到了类似的回复。为了获得客观的意见，至少在一个项目上坚持注释似乎是值得的。旅程的第一站将涉及大量样板代码：D