ORM 会导致糟糕的编码实践吗？ [关闭]答案

【问题标题】：Does ORM lead to bad coding practices? [closed]ORM 会导致糟糕的编码实践吗？ [关闭]
【发布时间】：2013-03-11 00:50:45
【问题描述】：

我们的团队在 PHP 中使用 ORM，我在两个单独的项目中指出，尽管我们已经详细讨论了良好的 MVC 设计，但 ORM 似乎允许人们进行数据库查询来自 View 层并创建难以维护的代码。

我倾向于这样一种观点，即 ORM 使得在程序员没有想到的情况下进行查询变得太容易了。通过将 ORM 对象返回到视图层，程序员实际上是在将数据库连接泄漏到不应该有它的层。

我在这里正确地考虑 ORM 吗？如果是这样，为什么它如此受欢迎？如果我没有正确地考虑它，我应该如何解决这些问题？

【问题讨论】：

我已经回答了，但有兴趣知道您使用的是什么 ORM。
另外，你有没有尝试过简单的架构规则，比如“瘦控制器，胖模型”？
Symfony 不是 ORM。 :) Propel 还是 Doctrine？
我的意思是说内置的Doctrine ORM模块。
我一直的心态是：胖服务层瘦控制器&瘦DAO层（本例是ORM层，虽然我个人更偏向于单独的模型和自建的DAO层)。

标签： php orm coding-style doctrine

【解决方案1】：

我会说你没有正确地考虑它。 ORM 本身并不会促进不良做法，至少不会以您体验它的方式。

ORM 是一个工具，就像任何其他框架、api 或其他任何东西一样，您可以正确使用它也可以不正确使用它。

这听起来更像是您团队中的开发人员对 MVC 模式没有清晰的理解。我首先要解决这个问题。

我认为 MVC 模式的一个常见问题是，开发人员倾向于将视图和控制器用于他们不应该做的事情。原因可能有很多，但每当你使用这样的东西时，我相信问题通常始于类似于这种想法的东西：

“这么简单的小事，我就在这里做，有在那里做这一切没有意义。”

基本上，在尝试解耦设计和业务逻辑时，总会有这样的情况，即在表示层中实现一些实际上属于业务层的部分会更容易。这不一定意味着开发人员很糟糕，但它可能表明缺乏经验或懒惰。我知道我曾多次犯过这件事，比如在为 Android 开发时（虽然从不专业:)）。

尝试找出一些示例案例，这些案例使用了您注意到的一些不良做法，并拥有某种编码道场，您作为一个团队可以使代码变得更好并正确实施，如果您有时间，展示拥有属于它们的东西的实际好处。我强烈建议您不要使用实际代码，除非您自己编写了代码，或者负责该代码的开发人员可以接受在其他开发人员面前被破坏。但这显然取决于您公司的文化以及开发人员是否对这类事情感兴趣并持开放态度。我个人希望在我的工作场所拥有类似的东西。

【讨论】：

【解决方案2】：

我不知道在视图层中有小的 ORM 调用是必然不好的。例如，我可能将foreach (Category::getAll() as $Category): 作为循环来列出页面上的类别。连接不会泄漏到视图的范围内（或者无论如何它当然不应该），因为它是由 ORM 封装的。我可以在控制器中分配此调用的结果，并将对象数组传递给模板（我当然会使用更复杂的调用），但 imo 微不足道的情况在视图中很好。

根据我的经验，ORM 的最大问题是“n+1”数据库查询计数的增长。通常，屏幕上的 one:many 列表可以从单个查询呈现，但 ORM 使得对一个表使用主循环非常方便，然后对辅助表的每个实例进行单独的选择。这是低效的，但您只会注意到当您的数据库开始因需要处理的查询数量增加而出现问题时。

最好的防范措施是让您的开发人员在开发模式下运行工具栏（例如 Symfony2 工具栏、PHP Debug 或类似工具），向他们显示构建屏幕所需的查询数量。当琐碎的屏幕开始需要超过 50 个查询（或您指定的任何上限）时，它们需要重构。

另外，选择具有合理表达查询语法的 ORM 是值得的，否则您的开发人员将回避“原始 SQL”模式，这会破坏首先使用 ORM 的一些原因。出于同样的原因 - Daniel 很好地说明了这一点 - 为您的开发人员提供有效使用 ORM 的培训是一个好主意。

【讨论】：

【解决方案3】：

从视图中进行查询是一种不好的做法。您可以这样做，但最好通过控制器通过 Ajax 请求或您认为合适的任何方式进行。

【讨论】：