最近由于rails的流行，很多人开始使用activerecord作为模型。然而，在我听说 rails 之前(我的同龄人不喜欢开源的东西，我们在 .NET 学校教过......)当我做最后一年的项目时，我发现了这个模型的定义
The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.
它并没有说模型应该像 activerecord 那样表示一个表。通常在一个事务中，可能需要查询一些不相关的表，然后操作来自不同表的数据......所以如果使用 activerecord 作为模型，那么任何一个都必须将所有逻辑代码塞入 Controller (这是在某些 php 框架中很流行)这使得很难测试或破解 activerecord 模型，以便它不仅对它映射到的表执行数据库操作，而且还对其他相关表执行数据库操作...
那么，滥用(恕我直言)activerecord 作为 MVC 架构模式中的模型有什么好处？
最佳答案
Martin Fowler 在 Patterns of Enterprise Application Architecture 中描述了这种模式以及其他两种模式或架构。这些模式适用于不同的情况和不同的复杂程度。
如果你只想做一些简单的事情，你可以使用事务脚本。这是您在许多旧的 ASP 和 PHP 页面中看到的架构，其中单个脚本包含业务逻辑、数据访问逻辑和表示逻辑。当事情变得更加复杂时，这种情况很快就会崩溃。
接下来您可以做的是在表示和模型之间添加一些分隔。这是事件记录。该模型仍然与数据库相关联，但你有更多的灵 active ，因为你可以在 View /页面/任何东西之间重用你的模型/数据访问。它不像它可能的那样灵活，但取决于您的数据访问解决方案，它可以足够灵活。像 .Net 中的 CSLA 这样的框架有很多来自这种模式的方面(我认为 Entity Framework 看起来也有点太像了)。它仍然可以处理很多复杂性而不会变得不可维护。
下一步是分离数据访问层和模型。这通常需要一个好的 OR 映射器或大量工作。所以不是每个人都想走这条路。领域驱动设计等许多方法都规定了这种方法。
所以这完全是上下文的问题。你需要什么，什么是最好的解决方案。有时我什至仍然使用事务脚本来编写简单的一次性代码。
关于php - activerecord 作为模型，这是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56546/