最佳实践：我是否应该创建一个新的控制器？为了尊重一个好的建筑答案

【问题标题】：best practice : should i create a new controller or not ? in order to respect a good architecture最佳实践：我是否应该创建一个新的控制器？为了尊重一个好的建筑
【发布时间】：2017-06-09 12:36:25
【问题描述】：

我正在开发一个既需要通知又需要历史记录的应用程序，而让它变得相当困难的是存在“上下文”的概念。

例如，当用户在某个视图中时，他必须只能看到与该上下文相关的通知和历史记录。每个都有一个控制器，但是当我想在客户端更新通知（使用 Pusher 实时更新）时，我需要从服务器端知道用户所在的上下文。解决方案是从客户端发送一个 ajax 请求，指定他所在的上下文，当然还有路由。

现在的问题是，为了尊重良好的架构，由于 ajax 请求发送的上下文用于通知和历史记录，我是否应该创建一个控制器来处理它（然后该控制器将联系两个控制器) 还是我应该使用其中之一？谢谢

【问题讨论】：

“上下文”有哪些类型？而且，是否因为其他原因需要使用 Ajax？
当用户在他的个人资料中时，他会看到所有通知，但是当用户在应用程序视图中时，他只能看到那些链接到该应用程序的通知。是的，使用 ajax 是必须的，如果您有任何其他选择以便在不重新加载页面的情况下向用户发送实时通知，我愿意接受。
老实说，我觉得通知模块不是控制器应该做的，而是控制器应该与之交互的东西。我会创建一个单独的模块，它是全局的，任何控制器都可以访问，然后你可以执行以下操作：控制器 -> 通知模块 -> 服务器 -> 通知模块 -> 控制器
使用 Pusher 时，你不能只使用控制器，因为 Pusher 使用他自己的服务器，基于套接字技术，为了让我的控制器工作，我必须使用 ajax。

标签： ruby-on-rails model-view-controller pusher

【解决方案1】：

是的，您可以为应用场景创建另一个命名空间/模块，并在其下放置另一个通知控制器。应用程序 id 必须在某个 url 中，然后控制器/操作将是它的子项，期望出现一个 @application 实例来过滤通知。

因此，您将在顶层下有一个控制器，但也在应用程序命名空间下。这样做的好处是您可以获得两个视图，因此您可以显示略有不同的内容，而无需在视图或操作方法中使用一堆条件逻辑。

当然，你也可以只有两条路由，把条件逻辑放在controller#action中，所以如果有一个application_id提交，过滤不同，这可能就是你现在正在做的。我更喜欢在路由上尽可能地将条件逻辑分开，这样我的控制器就更简单了。

理想情况下，Ajax 请求可以/应该以js 格式访问相同的控制器#action，因此它获取相同的信息并使用相同的查询，使用index.js.erb 而不是index.html.erb 呈现。

【讨论】：

首先感谢您的回答，我会再解释一下。通知和历史记录都被很多模型使用，不仅是应用程序，而且对于每个模型，我最多可以有 10 个上下文。为每条路线制作路线，将使 routes.rb 比现在要多得多。通知和历史与相关模型具有多态关联，并且它们都有自己的控制器，视图和控制器中都没有逻辑
听起来您可能想要一个多态控制器之类的东西，它可能只有索引和显示操作 - 需要一个“类型”和“ID”并以列表或单个对象响应。
我从未听说过多态控制器，如果您有任何好的链接，我愿意接受。正如我已经说过的，它与尊重 mvc 模式更相关，通知和历史记录的整个系统已经设计好并且运行良好。问题是，我应该创建一个控制器来处理上下文，然后他将调用 notificationController 和 historyController，还是我可以使用其中一个然后调用另一个？换句话说，上下文在两者之间是共同的，所以为了尊重模式，我不应该从另一个调用一个，或者它可以吗？