activerecord 作为模型，这是个好主意吗？答案

【问题标题】：activerecord as model, is this a good idea?activerecord 作为模型，这是个好主意吗？
【发布时间】：2010-09-08 13:33:12
【问题描述】：

最近由于 Rails 的流行，许多人开始使用 activerecord 作为模型。然而，在我听说 Rails 之前（我的同龄人不喜欢开源东西，我们在一所 .NET 学校接受过教育……），在我做最后一年的项目时，我发现了这个模型的定义

该模型代表企业数据以及管理对这些数据的访问和更新的业务规则。模型通常用作模拟真实世界过程的软件，因此在定义模型时应用简单的真实世界建模技术。

它并没有说模型应该像 activerecord 那样表示一个表。通常在一个事务中，一个人可能必须查询一些不相关的表，然后操作来自不同表的数据......所以如果使用 activerecord 作为模型，那么任何一个都必须将所有逻辑代码塞进控制器（这是在某些 php 框架中有点流行），这使得测试或破解 activerecord 模型变得困难，因此它不仅对它映射到的表执行数据库操作，而且还对其他相关表执行数据库操作......

那么，滥用（恕我直言）activerecord 作为 MVC 架构模式中的模型有什么好处？

【问题讨论】：

不，这是个非常糟糕的主意。

标签： php model-view-controller activerecord

【解决方案1】：

Martin Fowler 在企业应用程序架构模式中描述了这种模式以及其他两种模式或架构。这些模式适用于不同的情况和不同的复杂程度。

如果您只想做一些简单的事情，您可以使用事务脚本。这是您在许多旧的 ASP 和 PHP 页面中看到的架构，其中单个脚本包含业务逻辑、数据访问逻辑和表示逻辑。当事情变得更复杂时，这很快就会崩溃。

接下来您可以做的是在演示文稿和模型之间添加一些分离。这是活动记录。该模型仍然与数据库相关联，但您具有更多的灵活性，因为您可以在视图/页面/任何内容之间重用您的模型/数据访问。它不像它应该的那样灵活，但取决于您的数据访问解决方案，它可以足够灵活。 .Net 中的 CSLA 等框架有很多方面来自这种模式（我认为 Entity Framework 看起来也有点像这样）。它仍然可以处理大量复杂性而不会变得无法维护。

下一步是分离数据访问层和模型。这通常需要一个好的 OR 映射器或大量工作。所以不是每个人都想走这条路。领域驱动设计等许多方法都适用这种方法。

所以这完全取决于上下文。你需要什么，什么是最好的解决方案。有时我什至仍然使用事务脚本来编写简单的一次性代码。

【讨论】：

+1：提及 Martin Fowler 足以让您有理由为您的帖子投票。我相信任何考虑建模应用程序的人都应该尝试阅读他的书籍和论文。

【解决方案2】：

我多次说过，使用 Active Record（或几乎相同的 ORM）作为业务模型并不是一个好主意。让我解释一下：

PHP 是开源的、免费的（以及所有长篇故事......）这一事实为它提供了一个庞大的开发人员社区，他们将代码倒入论坛、GitHub 等网站、Google 代码等。你可能认为这是一件好事，但有时它往往不是“那么好”。例如，假设您正面临一个项目，并且您希望使用 ORM 框架来解决您用 PHP 编写的问题，那么……您将有很多 options to choose for：

教义
推进
QCodo
蛰伏
红豆

名单还在继续。定期创建新项目。所以想象一下，你已经构建了一个完整的框架，甚至是一个基于该框架的源代码生成器。但是您没有安排商务课程，因为毕竟“为什么要再次编写相同的课程？”。随着时间的流逝，一个新的 ORM 框架发布了，您想切换到新的 ORM，但您必须使用直接引用您的数据模型来修改几乎每个客户端应用程序。

最重要的是，Active Record 和 ORM 应该位于应用程序的数据层中，如果将它们与表示层混合使用，您可能会遇到像我刚刚放置的示例这样的问题。

听听@Mendelt 的睿智话语：阅读 Martin Fowler。他发表了许多关于 OO 设计的书籍和文章，并发表了一些关于该主题的好材料。此外，您可能想查看Anti-Patterns，更具体地说，查看Vendor Lock In，当我们使我们的应用程序依赖于第三方工具时会发生这种情况。最后，我写了this 博客文章谈到了同样的问题，所以如果你愿意，请查看。

希望我的回答对你有用。

【讨论】：

感谢您的回答，事实上，在与 ORM 合作一段时间后，我本人正在远离 ORM，因为它们有时非常不灵活。这些年来通过工作学到了很多：D
Doctrine 2 支持真正的域建模（与 Doctrine 1 不同），并允许您的数据库设计不同于域模型的设计。到目前为止，我对此感到非常满意。在这里查看：doctrine-project.org

【解决方案3】：

在 MVC 中使用 Rails ActiveRecord 作为模型的好处在于它为您提供了自动 ORM（对象关系映射器）和创建模型之间关联的简单方法。正如您所指出的，有时可能缺少 MVC。

因此，对于涉及许多模型的复杂事务，我建议在控制器和模型之间使用 Presenter (Rails Presenter Pattern)。 Presenter 将聚合您的模型和事务逻辑，并保持易于测试。您肯定希望努力将所有业务逻辑保留在您的模型或演示者中，而不是您的控制器中 (Skinny Controller, Fat Model)。

【讨论】：