没有视图的模型：Rails 中是否需要控制器
我想要一个推荐模型，其中用户 A 可以将事件 X 推荐给用户 B。我计划实现它的方式是不使用推荐视图。我只是在事件/显示页面上有一个用于创建操作的引用按钮，并在用户/显示页面中引用了用户以进行显示。我认为没有必要创建引用视图。
从设计模式的角度来看，是否可以在Events_Controller中创建“refer”操作来调用Referral模型中的create方法，而不是将其发送到指定的控制器（即Referals_Controller），该控制器将调用Referral模型？
更一般地说，即使我不需要这个特定模型的任何视图，我是否应该创建控制器以允许其他控制器与我的模型交互？
谢谢。
I would like to have a Referral model, where user A can refer an Event X to user B. The way I plan to implement it is without Referral Views. I just have a Refer button on a events/show page for create action, and have referred users in users/show page for show. I don't see the need to create a view for referral.
From design pattern point of view, is it OK to create "refer" action in Events_Controller to invoke create method in Referral model, instead of sending it to a designated controller (i.e., Refferals_Controller), which will make call to Referral model?
More generally, should I create controller to allow other controllers to interact with my model, even if I don't need any views for this particular model?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
控制器是 http 请求的来源（通过路由之后）。没有传入请求==没有控制器。当控制器符合 REST 方案（索引、显示、创建...）时，效果很好。但您也可以添加非 REST 操作（Rails 路由支持此操作：3 Non-资源丰富的路线)
与模型的所有交互可能都应该放在模型类中。（编辑：我的意思是代码）
Controller is where the http requests come (after passing through Routing). No incoming requests == no controller. Good when controller complies with REST scheme (index, show, create ...). But you can add non-REST actions as well (Rails Routing supports this: 3 Non-Resourceful Routes)
All interaction with model should probably go in the model class.(Edit: I mean code)
您不应该创建一个控制器来仅将调用从其他控制器转发到模型。每个控制器可以有多个模型。或者每个型号有多个控制器。
有时（如果您知道自己在做什么）您甚至可以直接从视图调用模型方法（“有些规则可以改变，有些可以打破”（c）Morpheus）。
You shouldn't create a controller to just forward calls to model from other controllers. You can have several models per controller. Or several controllers per model.
Sometimes (if you know what you're doing) you can even call model methods from the view directly ("some rules can be bent, some can be broken" (c) Morpheus ).