最近感谢rails的受欢迎程度，很多人开始使用activerecord作为模型。然而，在我听说过rails之前（我的同行小组不是开源软件的粉丝，我们是在.NET学校教过的......）当我在做最后一年的项目时，我发现了这个模型的定义< / p>
该模型表示企业数据和管理此数据访问和更新的业务规则。该模型通常用作现实世界过程的软件近似，因此在定义模型时可以使用简单的实际建模技术。
它没有说模型应该代表一个表作为activerecord的作用。通常在事务中，可能必须查询一些不相关的表，然后操纵来自不同表的数据......所以如果将activerecord用作模型，那么任何一个都必须将所有逻辑代码塞入控制器（这是在一些php框架中很受欢迎，这使得很难测试或破解activerecord模型，这样它不仅可以对它映射到的表执行数据库操作，而且还可以对其他相关表执行...
那么，滥用（IMHO）activerecord作为MVC架构模式中的模型有什么好处呢？
答案 0 :(得分：8)
Martin Fowler在企业应用程序架构模式中描述了这种模式以及其他两种模式或体系结构。这些模式适用于不同的情况和不同的复杂程度。
如果您只想使用简单的东西，可以使用事务脚本。这是您在许多旧的ASP和PHP页面中看到的体系结构，其中单个脚本包含业务逻辑，数据访问逻辑和表示逻辑。当事情变得更复杂时，这会迅速崩溃。
您可以做的下一件事是在演示文稿和模型之间添加一些分隔。这是积极的记录。该模型仍然与数据库绑定，但您可以更灵活，因为您可以在视图/页面/之间重用模型/数据访问。它不像它可能那么灵活，但根据您的数据访问解决方案，它可以足够灵活。像.Net中的CSLA这样的框架有很多方面来自这个模式（我认为实体框架看起来有点像这样）。它仍然可以处理很多复杂性而不会变得不可维护。
下一步是分离数据访问层和模型。这通常需要一个好的OR映射器或大量的工作。所以不是每个人都想这样做。很多像域驱动设计这样的方法论都采用了这种方法。
所以这完全是一个背景问题。您需要什么，什么是最佳解决方案。我甚至有时会使用事务脚本来获得简单的一次性代码。
答案 1 :(得分：2)
我已多次说过使用Active Record（或几乎相同的ORM）与商业模式不是一个好主意。让我解释一下：
PHP是开源，免费（以及长篇故事......）这一事实为它提供了大量的开发人员社区，将代码放入论坛，GitHub等网站，谷歌代码等等。你可能会认为这是一件好事，但有时它往往不是“那么好”。例如，假设您正面临一个项目，并且您希望使用ORM框架来面对用PHP编写的问题，那么......您将拥有大量options to choose for：
这个清单一直在继续。新项目定期创建。因此，假设您构建了一个完整的框架，甚至是基于该框架的源代码生成器。但是你没有放置业务类，毕竟“为什么要再次编写相同的类？”。时间流逝并且发布了新的ORM框架并且您希望切换到新的ORM，但是您必须使用对数据模型的直接引用来修改几乎每个客户端应用程序。
底线，Active Record和ORM应该在您的应用程序的数据层中，如果您将它们与您的表示层混合，您可能会遇到类似我刚刚奠定的示例的问题。
听听@Mendelt的明智话语：阅读Martin Fowler。他在OO设计上放了很多书和文章，并发表了一些关于这个主题的好材料。此外，您可能希望查看Anti-Patterns，更具体地说是Vendor Lock In，这是当我们使应用程序依赖于第三方工具时会发生的情况。最后，我写了一篇关于同一问题的this博客文章，所以如果你愿意的话，请查看。
希望我的答案有用。
答案 2 :(得分：1)
在MVC中使用Rails ActiveRecord作为模型的好处在于它为您提供了一个自动ORM（对象关系映射器）以及在模型之间创建关联的简便方法。正如您所指出的，MVC有时可能缺乏。
因此，对于涉及许多模型的复杂事务，我建议在控制器和模型之间使用Presenter（Rails Presenter Pattern）。 Presenter将汇总您的模型和事务逻辑，并且仍然可以轻松测试。您肯定希望努力将所有业务逻辑保留在模型或演示者中，以及控制器之外（Skinny Controller, Fat Model）。