rails ajax 调用是不是应该捆绑到它们自己的单独控制器中？

Posted 2023-02-16

【中文标题】rails ajax 调用是不是应该捆绑到它们自己的单独控制器中？

【英文标题】：Should rails ajax calls be bundled into their own separate controller?rails ajax 调用是否应该捆绑到它们自己的单独控制器中？

【发布时间】：2010-11-14 01:33:37

【问题描述】：

非 RESTful 的 AJAX 调用应该是：

放入最适合其功能/视图的控制器，或 捆绑到他们自己单独的“Ajax”控制器中？

我一直在做 1，但我刚刚阅读了这篇 (2725 diggs) 文章http://zygote.egg-co.com/10-dirty-little-web-development-tricks/（见第 9 点） 这个小伙子选择了方法2。但他是一个php开发人员。

一个好处可能是 2 可能会通过执行 'ajax/:action' 之类的操作来清理路由，而不是向 restful 路由添加成员。

这似乎是一个 6.5 的一个，半个面包师的打的其他类型的东西。

你会选择哪个？

【问题讨论】：

感谢您的回复。你回应了我自己的观点，他们应该进入自己的控制器。大佬 PHP 先生应该改变他的方式！ ;)

【参考方案1】：

我更喜欢第一种方法：

它在语义上是一致的。如果 Ajax 操作涉及资源 XXX，您（和其他编码人员）将知道在应用程序中的何处查找内容，这要归功于 Rails 约定。 如果您的应用程序在 Ajax 上很重（现在大多数都是），那么您最终会得到一个否定整个 RESTful 事物的庞然大物 AjaxController。您的其余控制器将在那里提供优雅降级的非 javascript CRUD 操作。 同样，测试您的 Ajax 控制器往往会有些混乱，因为您必须为应用程序的每个“ajaxified”资源设置场景——加载固定装置、模拟等。

【参考方案2】：

您的“RESTful”控制器可能包括new 和edit 操作，它们实际上都不是RESTful，它们只是为create 和update REST 操作提供用户界面。 new 和 edit 没有获得单独的 NonRestUIController 或其他东西，它们保存在相关资源的控制器中，使您的控制器在语义上保持一致。同样，与特定功能集或特定资源相关的 Ajax 操作应保留在关联的控制器中。

【讨论】：

REST 与新建/编辑或创建/更新无关。我不确定你的意思是什么。

这正是我的观点。它们实际上与 REST 没有任何关系，但它们被保存在所谓的 RESTful 控制器中，与它们相关联的资源一起保持简单。我的意思是对 Ajax 操作做同样的事情并没有太大的不同。