根据我目前的理解,如果我必须描述rails应用程序的各个组件如何协同工作以响应请求,我会说以下内容:
1)路由确定哪些请求URL映射到哪些控制器方法。
2)控制器方法从模型中获取信息,并将该信息(以全局变量的形式)传递给相应的视图模板。
3)视图模板使用存储在全局变量中的数据来构建最终响应。
在上面的解释中,几个组成部分之间的关系是明确的,不可否认的;即:
1)路线和控制器方法
2)控制器方法和视图模板
事实上,上述关系是1对1。
然而,模型类与其相邻组件类型(即控制器)的关系并不清楚。是的,控制器从模型中检索信息,但请考虑以下事项:
1)控制器不一定需要从模型中检索信息,就像静态网站的情况一样。
2)控制器可以从多个模型类中检索信息。
因此,准确地说模型与其他组件分开存在更准确吗?将模型类组合在一起构成应用程序后端的后端,而其他组件(即路由,控制器方法和视图模板)构成紧密耦合,是否准确无误?线性机制,其中控制器根据需要浸入模型类?更具体地说,至少在轨道组件如何实际组合在一起的情况下,是否准确,是否在任何给定控制器和任何给定模型(例如UserController和User)之间没有自然关系?
是的,我知道rails附带了“resources”关键字,用于在路由文件中生成RESTful路由,并且通常在rails中以RESTful方式完成。您可以说rails适用于RESTful Web应用程序的开发。在RESTful应用程序的上下文中,模型和控制器隐含地相互关联。但这是对REST架构风格的描述。我问的是铁轨。在我看来,在rails本身中,模型只与控制器相关,只要模型用于控制器方法的实现 - 并且因为软件中的代码组织是任意的,这些关系是任意的。
我正在考虑这些事情,因为我想为用户添加一种查看自己的个人资料的方法。我已经有了用户模型和控制器以及用于显示用户信息的视图。配置文件页面将显示来自用户模型的信息,但我不想使用与用户自己的配置文件相同的控制器或视图来显示有关其他用户的信息。因此,我计划为配置文件创建一个新的控制器和视图,但使用User模型来检索显示的信息。这是一个随意的决定,就像构建应用程序时做出的其他任意决定一样。但是,如果出于某种原因,模型和控制器应该在轨道中保持紧密耦合(例如1对1),那么这将不是一个有效的决定。
任何人都可以确认或反驳我在说什么吗?
答案 0 :(得分:0)
创建独立控制器很好。您还可以创建指向UsersController#show
操作的路线,并在用户查看其自己的个人资料时处理该案例。
在一个非常重要的应用程序中,你最终会得到与资源不匹配的控制器和没有控制器的模型,而且没问题。
在您的情况下,您可能想要的只是一条不同的路线(例如:www.example.com/me
),这并不意味着行动逻辑不能在UsersController
中。最后,所有这些都是为了在一个地方保持类似的逻辑,以便更容易维护。
答案 1 :(得分:0)
有关MVC的详细解释,请查看Jeff Atwood的帖子:http://blog.codinghorror.com/understanding-model-view-controller/
现在,对于您的应用,一个控制器可以很好地显示用户的个人资料页面。您应该做的是确保安全性,对于UsersController#show action(配置文件页面),您应该验证它是当前用户,否则重定向,或显示错误消息,或显示可编辑页面等。
@user = User.find(params[:id])
if current_user != @user
render :show
else
render :self_profile
end
您可以使用的另一种方法是:
@user = User.find(params[:id])
if current_user != @user
@authenticated_user = true
end
render :show
然后在您的视图模板中,您可以拥有一个条件:
<% if @authenticated_user %>
#Edit button here, takes you to the settings page
<% else %>
#Follow button here
<% end %>
current_user应该是应用程序控制器中定义的helper_method。