Doctrine2中实体描述注释的优点是什么？
在Doctrine1＆amp; Propel（我已经多次使用过），对数据库进行逆向工程以创建yml或xml，然后生成模型是一个非常快速的工作流程。
在Doctrine2中，选择注释，必须编写大量的锅炉板代码才能使实体到位。然而，注释似乎是“走的路”。
我错过了什么？
答案 0 :(得分：29)
您从D1和推进中描述的工作流程与Doctrine2的首选思维方式完全相反。实际上，我也避免在D1中编写自己的数据库定义，这主要与我在这里给出的原因相同：
在学说2中，您首先关心的是您的实体。实体只是普通的PHP对象，而且doctrine只处理你的持久性。事实上，Doctrine在某些数据库中隐藏数据背后的事实实际上是事后的想法。所有这些混乱正是你应该抽象出来的！从理论上讲，你可以在将来某个日期摆脱教义，并编写自己的持久性逻辑。您的实体仍然可以像以往一样工作。
以这种方式看待，从数据库模式开始是非常愚蠢的。您对实体以及嵌入其中的业务逻辑更感兴趣。那是美味的汤！
现在，既然你正在使用doctrine来实现你的实体的持久化，那么（可能）将你的映射数据与类定义保持在一起是有意义的。
所以你的新工作流程是：
./doctrine orm:schema:create让学说担心
数据库表定义。现在，如果你有一些遗留数据库，事情会变得棘手而且乐趣也就少了很多。我没有真正用D2来处理这种情况，但我认为这很难看。
关于Boilerplate代码：我看到人们抱怨必须为他们的实体编写getter / setter。我做类似的事情what this guy does - 我的所有实体都扩展了一个AbstractEntity类，该类使用魔术方法为任何没有手工制作的属性生成getter / setter。一旦你这样做，几乎没有锅炉板。
或者，现在有很多工具可以为你敲定样板（PHPStorm会这样做，Sublime的插件等）。这使得锅炉板相当轻松，并且具有额外的优势，您可以添加类型提示，并且您的编辑器可以提供有用的自动完成。
答案 1 :(得分：10)
我在yml或xml上使用注释的主要原因是易于配置。我不必查看另一个文件来记住（例如）我在ManyToMany关系中设置连接表名称的内容。如果我在域对象中更改某些内容（这在我的开发过程中很早就会发生），我也不必记得使用更改来更新另一个配置文件。
但是，正如您所说，数据库架构更容易移植到其他配置格式之一，因此在这种情况下，您最好使用yml或xml而不是注释。最终归结为个人偏好......使用你最熟悉的东西。