ruby-on-rails – 具有存储库模式的Ruby on Rails?

前端之家收集整理的这篇文章主要介绍了ruby-on-rails – 具有存储库模式的Ruby on Rails?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在使用ASP.Net MVC之后,它让我想起了Rails.我以前和Rails一起工作,但有点生锈. ASP.Net MVC教程推荐使用存储库模式隐藏数据层实现.这允许用于单元测试的easiesr依赖注入,以及控制器与模型实现的良好解耦.

我记得直接使用Active Record对象的Rails控制器,使用可以轻松设置和拆卸的测试数据库进行单元测试.这解决了需要交换单元测试,但是在控制器中暴露的ActiveRecord代码仍然是一个坏主意.

所以我的问题是,这里最新的最佳做法是什么?实际(不嘲笑)数据库是否仍然用于单元测试? Rails开发人员直接调用ActiveRecord还是抽象?

解决方法

ActiveRecord甚至真的构成了“数据层”,我不知道?毕竟,其目的是抽象(相当合理的程度)实际的交互存储.如果我有一个从ActiveRecord :: Base继承的模型,并且在控制器中引用该模型,那么我真的与数据层进行了交互吗?

看看Repository Pattern的简要描述我会说find_by_的方法已经给你很多的描述,这是好的,不是吗?好的,抽象层是泄漏的(可能会更慷慨地说“务实”),因为我们可以更加接近金属,如果需要的话,find_by_sql将会很明显地表明我们正在处理一个关系某种数据库

我建议从来没有(或者也许我应该说“很少,而不是没有极端的理由” – 使用绝对总是棘手的)将代码放在控制器中,使得可以推断使用的数据平台.它应该被推入模型 – named_scope在这里可以非常有用.对于复杂的结果,请考虑使用“presentation”对象作为界面(Struct和我个人喜欢的OpenStruct在这里非常有用).

虽然ActiveRecord是事实上的标准,考虑到它安装与Rails,它不是在城里唯一的游戏.对于非sql数据库,需要不同的东西,但即使在sql域中也有Datamapper(基于eponymous PoEAA pattern?)

在Rails 3.0中,pick and choose components将会更加容易,比如ORM为Yehuda,男孩们打开并清理了界面.

猜你在找的Ruby相关文章