我如何知道何时以及是否为一段代码使用单独的控制器？
因此，我面临的情况是，我必须决定是否为特定代码段使用单独的控制器。 我们有一个主页，它就像网站其他部分的中心。 所有用户（已登录和未登录）都可以访问该页面。 我正在考虑将 home 作为一个单独的控制器和一个名为 index 的操作。 考虑到这种情况，我开始想知道这方面是否有任何规则或指导方针。
我的看法是，如果代码围绕一个实体，则需要分离。 （与 REST 准则类似）如果实体是名词，则它应该是控制器。 如果实体是动词，那么它可能应该是一个动作，并且应该驻留在控制器中，控制器的名称与动词所指的名词的名称相同。 一些同事建议，由于这是一个操作，因此它应该驻留在某个现有的控制器中，并且应该命名为 home。 我强烈不同意，但是，我找不到可靠的消息来源来支持我的观点。
想知道您的想法。
So I am in a situation where I have to decide whether or not to have a separate controller for a particular piece of code. We have a home page that acts like a hub for the rest of the site. The page is accessible to all users (logged in as well as non-logged-in). I was thinking about having home as a separate controller and an action called index. Thinking about this situation, I started wondering if there are any rules or guidelines on this front.
My perception has been that if a code revolves around an entity, separation is needed. (Similar to REST guidelines) If the entity is a noun, it should be a controller. If the entity is a verb, it should probably be an action and should reside in the controller whose name is the same as that of the noun that the verb refers to. Some colleagues suggested that since this is one action, it should reside in the some existing controller and should be named home. I strongly disagreed, however, I could not find a trusted source that would back me up on this.
Would like to know your thoughts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在这种情况下，我必须同意你的同事的意见。
正如您所说，在处理资源时，REST 是一种很好的方法。 这允许您创建一致的界面，尤其是为了创建 Web 服务。
然而，REST 实际上并不能很好地映射到 Web 浏览器设置。 例如，您会注意到，即使对于资源，您的 /edit 和 /new 操作也只是 GET 请求，返回指向相关 RESTful 操作的 HTML 表单。 “编辑”和“新建”根本不是 RESTy。
同样，主页通常是用户友好的各种数据的合并，不适合 RESTful 界面。 因此，要么只在一个操作中添加一个额外的控制器，要么使用现有控制器的“列表”操作作为主页
In this case I have to agree with your co-workers.
REST is a nice approach to take when dealing with resources, as you say. This allows you to create a consistent interface especially with a view to creating a web service.
However REST doesn't actually map too well to a web browser setting. You'll notice for example that even for resources your /edit and /new actions are just GET requests returning an HTML form pointing to the relevant RESTful action. 'edit' and 'new' aren't RESTy at all.
Similarly, the home page is generally a user-friendly amalgamation of various data, not suited to a RESTful interface. So either just stick an extra controller in with one action, or alternatively use an existing controller's 'list' action as the home page
问题从这句话开始
如果您尝试构建 RESTful 架构，则实体不能是动词。 如果您使用 HTTP，则唯一允许使用的动词是 GET、PUT、POST、DELETE、HEAD、OPTIONS。 所有实体都应该映射到某个名词，如果您尝试检索该实体，您应该使用动词 GET。 就个人而言，我会将其映射到控制器上的 Get() 方法，但我不知道 Rails 是否允许您这样做。
The problem starts with the phrase
If you are attempting to produce a RESTful architecture, an entity cannot be a verb. The only verbs allowed if you are using HTTP are GET, PUT, POST, DELETE, HEAD, OPTIONS. All entities should be mapped to some noun and if you are trying to retrieve that entity you should be using the verb GET. Personally, I would map that to the method Get() on my controller but I don't know if Rails lets you do that.
快速（且无用）的答案是，无论哪种方式都可以正常工作。
我认为每个人都会在某一时刻遇到这个决定，而你做出的决定取决于网站可能的未来......这意味着它很容易过早优化......但这始终是问题所在，
正如你可能已经猜到的那样到目前为止，“家”在某种程度上既是动词又是名词，这就是为什么你不知道该怎么做。
答案取决于对网站结构的解释以及您可用的时间的组合...
如果您没有多少时间来处理此问题...那么将“主页”操作填充到另一个控制器中通常被认为是权宜之计。 它有效，它可以让你转移到其他（可能更有成效的）任务上。
然而，我同意有时退一步思考你正在做的事情以及是否可以做得“更好”是件好事......
在这种情况下，尽管很难定义“更好” - 因为将主页操作放入新控制器中不太可能明显更快......并且如果这是控制器中的唯一操作......它是否更好是有争议的，从架构上讲，只是将其添加到现有的控制器上......
所以我们开始进行主要是哲学辩论......换句话说，没有一个答案会比另一个答案“更正确” - 这更多是一个品味和问题环境。 在这种情况下，争论的焦点在于如何使结构更加 RESTful。
为了忠实于 RESTful 架构，您确实可以将操作移动到它自己的控制器中......但您首先必须确定实体是什么。 “主页”页面通常不容易识别为特定的数据库实体......它更常见的是门户页面。
有时您可以选择一个实体，例如在线商店通常会有一个实际上是“products#index”变体的主页，或者有时“主页”页面是 UserAccount#show 页面...但更常见的是，您的主页将并不简单，并且会结合来自多个实体的信息……因此很难决定什么是“正确的”架构。
如果您无法识别特定实体，那么对于是否将操作移至特定控制器存在有效的争论。
但是，您始终可以创建一个以站点架构为中心的新“实体”。 如果您要为网站提供其他非特定于实体的页面（例如条款和条件或“关于我们公司”页面），这种情况尤其可能发生。
通常的后备是“PageController”（或类似名称），它不链接到 Active Record 模型，而是链接到一个更模糊的实体，在本例中是一个可识别的“页面”网站的用户（例如“主页”、“条款与条件页面”和“关于页面”）。 每个操作都针对特定页面...
因此，这取决于您是否更适合您对系统架构的看法...以及是否值得付出努力...但这就是我的看法辩论。 :)
The quick (and unhelpful) answer is that either way works fine.
I think that everybody comes across this decision at one point, and the decision you make depends on the likely future of the website... which means it's prone to premature optimisation... but that's always the catch,
As you've probably guessed by now, "home" is in some ways a verb as well as a noun, thus why you're having trouble figuring out what to do.
The answer depends on a combination of interpretation of your website structure and how much time is available to you...
if you have very little time to work on this... then stuffing the 'home' action into another controller is often considered the expedient option. It works, it lets you move onto other (probably more productive) tasks.
However, I agree that sometimes it is good to step back and think about what you're doing and whether it could be done "better"...
in this case, though it's harder to define "better" - as it's unlikely that putting the home action in a new controller would be measurably faster... and if it's the only action int he controller... it's debatable whether it's better, architecturally, to just adding it onto an existing controller...
So we start in on what is mostly a philosophical debate... in other words, no answer will be "more correct" than the other- it's more a matter of taste and circumstance. In this case, the debate hinges on making the structure more RESTful.
To be faithful to RESTful architecture, you would indeed move the action into it's own controller... but you'd first have to identify what the entity is. The "home" page is often not readily identifiable as a specific db entity... it's more often a portal-page.
Sometimes you can pick an entity eg online shops will often have a home page that is actually a "products#index" variation, or sometimes the "home" page is a UserAccount#show page... but more often, your home page will not be simple, and will combine information from multiple entities... thus why it is difficult to decide what the "right" architecture will be.
If you cannot identify a specific entity, then there is a valid debate as to whether to move the action into a specific controller.
however, you can always create a new "entity" that is centred around the architecture of the site. This is especially likely if you are going to come up with other non-entity-specific pages for the site (eg T&Cs or an "about our company" page).
The usual fallback being a "PageController" (or similar name) which isn't linked to an Active Record model, but to a more nebulous entity, in this case a "page" which is recognisable to a user of the website (eg the "home page" and the "T&C page" and the "about page"). Each action would be for a specific page...
So, it's up to you as to whether this fits better with your view of the architecture of your system... and whether it's worth the effort... but that's my view on the debate. :)