activerecord作为模型,这是一个好主意吗？

最近感谢rails的受欢迎程度,很多人开始使用activerecord作为模型.然而,在我听说过rails之前(我的同行小组不是开源软件的粉丝,我们是在.NET学校教过的......)当我在做最后一年的项目时,我发现了这个模型的定义

该模型表示企业数据和管理此数据的访问和更新的业务规则.通常,模型用作现实世界过程的软件近似,因此在定义模型时应用简单的现实建模技术.

它并没有说模型应该代表一个表作为activerecord的作用.通常在事务中,可能必须查询一些不相关的表,然后操纵来自不同表的数据......所以如果将activerecord用作模型,那么任何一个都必须将所有逻辑代码塞入控制器(这是在一些PHP框架中很受欢迎,这使得很难测试或破解activerecord模型,这样它不仅可以对它映射到的表执行数据库操作,而且还可以对其他相关表执行数据库操作...

那么,滥用(IMHO)activerecord作为MVC架构模式中的模型有什么好处呢？

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

如果您只想这么简单,可以使用Transaction Script.这是您在许多旧的ASP和PHP页面中看到的体系结构,其中单个脚本包含业务逻辑,数据访问逻辑和表示逻辑.当事情变得更复杂时,这会迅速崩溃.

接下来你可以做的是在表示和模型之间添加一些分隔.这是积极的记录.该模型仍然与数据库绑定,但您可以更灵活,因为您可以在视图/页面/之间重用模型/数据访问.它不像它可能那么灵活,但根据您的数据访问解决方案,它可以足够灵活.像.Net中的CSLA这样的框架有很多方面来自这个模式(我认为实体框架看起来有点像这样).它仍然可以处理很多复杂性而不会变得不可维护.

下一步是分离数据访问层和模型.这通常需要一个好的OR映射器或大量的工作.所以不是每个人都想这样做.很多像域驱动设计这样的方法论都采用了这种方法.

所以这完全是一个背景问题.您需要什么,什么是最佳解决方案.我甚至有时会使用事务脚本来获得简单的一次性代码.