ActiveResource是否存在根本缺陷？

Question

来自不同团队的几位开发人员独立告诉我,ActiveResource是一个有缺陷的想法.我听到的最常见的批评是将它设计为具有类似ActiveRecord的界面是错误的.我也听到有关错误处理方式或吞噬方式的投诉.一个开发人员实际上创建了自己的gem来提供与ActiveResource(基于RESTful资源的模型的框架)相同的功能.

我是ActiveResource的新手,但是当我查看代码并进行实验并了解它是如何工作的时候,我很难看出阻力来自哪里.它似乎基于干净,坚实的概念.我甚至听说它太重了!但在我的检查中,我发现它轻快.

因此,关于ActiveResource的所有争议,我转向网络寻求答案.当然,必须有一堆博客文章,说明为什么应该使用ActiveResource来支持X.毕竟,我确实可以找到关于DataMapper是否优于ActiveRecord的帖子.所以我搜索过,我搜索过......没什么.没有一件事.我无法在互联网上找到任何批评ActiveResource的页面(除了对REST的全面批评).我甚至找不到建议的替代方案.它得到了Rails核心团队的支持,似乎是社区中事实上的标准.

底线:

有关ActiveResource的争议吗？如果是这样,辩论的本质是什么？还有替代品吗？

Answer 1

自2007年以来,我一直在广泛地使用ActiveResource,并且在Rails从v1.2升级到v4.0期间,使用ARes构建并维护了一个多服务分布式架构.在我看来战神是在其当前形式的公共图书馆根本性的缺陷,但它含有大量的可投入到各个系统中使用的好点子.我谈了一下我们在公司做些什么来迁移到ARes.

人们在实践中不喜欢AR的一个重要原因是他们不同意维护或实施细节.处理您的同事的错误消息属于此类别.此外,随着时间的推移,你会发现由于不明智的一次性改进或错误修复,甚至Rails内部变化渗透而意外突破(例如,当YAML-pocalypse去年袭击时,我们的ARes遭遇灾难性崩溃)系统).但是所有这些都可以通过更好的维护和更好的视觉来改善,将这些问题与基本问题分开是很重要的.

我已经开始相信,以及Yehuda在上面的评论中提到的是,ARes失败了,因为REST API没有一般的具体语义.即使利用最好的Rails约定,HTTP API语义充其量只是脆弱的.

与ActiveRecord所做的相比,它生成SQL:一种定义明确的声明性语言,用于选择数据行.SQL基于关系模型,它为我们提供了基于不同子句的查询含义的数学定义.这个数学基础是允许像Arel这样的东西在ruby中创建一个可组合的SQL DSL.在SQL数据库中,可以执行任何语法正确的查询(即使它太慢而不实用),因为该引擎旨在正式解析和映射SQL语句,以证明正确的操作和获取底层数据的实现.因此,当您在此基础上构建类似ActiveRecord的ORM时,您在底层系统中具有非常强大的保证.如果生成有效的SQL引擎保证它可以工作,如果生成无效的SQL,引擎会返回错误.即使有了SQL的标准化,值得注意的是每个数据库都有一个单独的ActiveRecord适配器,以确保正确性和正确映射到ActiveRecord功能.其中每个都使用底层驱动程序来保证正在运行的数据库的正确的线程协议实现.所有这些代码都有相当多的规范和维护,所有这些都能够实现当今ActiveRecord的良好优雅和可靠性.

现在考虑一个HTTP API及其支持？它可能是任何数据库技术在阳光下或根本没有!它很可能是内部编写的,只提供业务功能所必需的功能.与在其模式中携带有关泛型查询操作的所有必要信息的数据库不同,HTTP API与任何底层存储机制或业务逻辑完全分离.即使API为如何使用查询参数提供了标准,也没有可用的过滤器或排序选项的自我文档定义.哎呀,即使检查params的有效性也不能得到保证,因为API通常不会吞没或忽略无效的参数.

总而言之,ARes非常方便,但它建立在流沙之上.它使用的想法和惯例很方便,但它们缺乏凝聚力和可靠性的稳定性.就个人而言,我认为使用自己的约定和可靠的规范来推动您的ARes看起来相似,然后您可以将其应用于您的服务实现并非不合理.

在建立基础之上,像ARes这样的东西是有意义的,Yehuda Katz和Steve Klabnik的优秀JSON:API规范是一个伟大的社区项目,将提供这样一个基础的一个非常重要的构建块,但是值得注意的是在语义保证和可派生功能方面,它仍然不会出现在特定数据库驱动程序附近的任何地方.我怀疑,与RDBMS相比,利用JSON-API的非常好的ARes类库与今天的内容有很大不同,以更好地接受adhoc API中隐含的灰色区域.

编辑:JSON:经过两年的激烈争论和来自不同社区的反馈,API刚刚达到1.0.我估计在这个规范中投入的工作量比ActiveResource实现的工作量高出几个数量级.尽管它与ActiveResource具有不同的抽象级别,但JSON:API追求的目标是提供标准语义,以便API更易于生成和使用.查看一些实现可以很好地了解JSON:API可以提供多少杠杆.

Answer 2

在 Rails 4.0 中，ActiveResource 已从 Rails 中移除。

很多人只使用 RestClient 或 HTTParty 或其他库。这些库通常被认为更简单、更易于使用。