在使用 ASP.Net MVC 之后，我开始考虑 Rails。我之前使用过 Rails，但有点生疏。ASP.Net MVC 教程建议使用存储库模式隐藏数据层实现。这允许更轻松的单元测试依赖注入，以及控制器与模型实现的良好解耦。
我记得 Rails 的控制器直接使用 Active Record 对象，以及使用可以轻松设置和拆除的测试数据库的单元测试。这解决了更换单元测试的需要，但在控制器中公开这么多 ActiveRecord 代码似乎仍然是个坏主意。
所以我的问题是，这里最新的最佳实践是什么？真实（非模拟）数据库是否仍用于单元测试？Rails 开发人员是直接调用 ActiveRecord 还是抽象？
我的经验是 Ruby on Rails 如此紧密地集成了 ActiveRecord（在大多数情况下，它可以变得几乎完全透明），以至于开发人员经常在没有任何抽象的情况下使用它。
需要记住的是，存储库模式和活动记录模式都在Martin Fowler 的企业架构模式中提出（如果你还没有阅读过……你应该阅读它）。Active Record 紧密集成在 Rails 中。Microsoft .NET 不会将您与某种模式联系起来……因此，大多数开发人员都采用了存储库模式。
我想知道 ActiveRecord 是否真的构成了“数据层”？毕竟，它的目的是抽象（在相当合理的程度上）实际的交互存储。如果我有一个继承自的ActiveRecord::Base模型并在控制器中引用该模型，我真的与数据层交互吗？
看一下Repository Pattern的简要描述，我想说 的方法find_by_已经为您提供了它所描述的大部分内容，这很好，不是吗？好的，抽象层是有漏洞的（有人可能会更慷慨地说“实用”），因为如果需要，我们可以更接近金属，find_by_sql例如，很明显我们正在处理一个关系数据库某种。
我建议永远不要（或者我应该说“很少而且不是没有极端理由” - 使用绝对值总是很棘手）将代码放入控制器中，从而可以推断出正在使用的数据平台。它应该全部推入模型中 -named_scope在这里非常有用。对于复杂的结果，考虑使用“演示”对象作为界面（Struct我个人最喜欢的OpenStruct在这里可能非常有用）。
虽然 ActiveRecord 是事实上的标准，但鉴于它与 Rails 一起安装，它并不是城里唯一的游戏。对于非 SQL 数据库，需要一些不同的东西，但即使在 SQL 域中也有 Datamapper（是基于同名的 PoEAA 模式吗？）
在 Rails 3.0 中，选择和选择诸如Yehuda的 ORM 之类的组件将变得容易得多，而男孩们则可以取消选择并清理接口。
无论哪种方式，你都可以做到。大多数情况下，编写 Rails 功能测试一直到数据库，正如您所描述的那样，数据是从固定装置填充的。
但是模拟出服务层调用并不少见，例如：
User.expects(:find_by_id).with("1").returns(u);
get :show, :id=>"1"
... 或类似的东西。事实上，我一直这样做是为了控制模型对象（或者模拟出来）。
遵循 Rails 约定总是会导致最不痛苦的记忆之路，因此建议这样做。
根据您对“真实”的定义...对于单元测试，我发现人们倾向于使用与主站点相同的数据模式，并在测试运行之前/测试期间为数据库播种（通过使用 Factory Girl ，机械师或普通的 ol' 夹具），然后根据该数据运行测试。
Rails 开发人员直接在此数据上调用 ActiveRecord，就像在现实世界中一样。
控制器应该访问 MVC 中的模型。Rails 就是要避免企业世界中一些不必要的抽象。