我正在寻找关于何时知道何时对模型进行RESTful处理以及它的关联是否正确以及什么时候不正确的指南。也许这是我当前应用程序的本质,但我发现没有关联的简单模型可以很好地与REST协同工作,但是具有许多has_many关联的复杂模型似乎使控制器中所需的视图和设置变得复杂。 form_for调用开始变得特别复杂。
或许这是我对新手的理解。我已经做Rails已经有三年多了,但REST和帮助伙伴似乎让我神秘化了。
答案 0 :(得分:5)
为系统中的每个顶级模型创建资源。在顶级,我的意思是独立的模型,并且在相关模型之外具有意义。一般来说,这是大多数模特。在以下示例中,Position和Candidate是顶级的。您可以认为候选人由过去就业和她申请的职位组成。可以通过候选资源访问职位和先前工作历史的申请,因为他们不存在。
<强>模型强>
class Position
has_many :candidate_positions
has_many :candidates, :through => :candidate_positions
end
class Candidate
has_many :candidate_positions
has_many :positions, :through => :candidate_positions
has_many :past_employments
accepts_nested_attributes_for :past_employments
accepts_nested_attributes_for :candidate_positions
end
class PastEmployment
belongs_to :candidate
end
class CandidatePosition
belongs_to :candidate
belongs_to :position
end
<强>路线强>
map.resources :positions
map.resources :candidates
使用非资源控制器与跨越模型的用户进行交互。例如,如果您想要显示可用位置的HomeController
以及最近的候选者,那么这将是一个新的普通控制器。如果你想编辑这个控制器上的任何信息,请冷静!您已经拥有可用于处理表单帖子的控制器,这些控制器将自动与<% form_for @candidate %>
连接。您可以使用<%= render @positions %>
呈现您的位置集合,并且因为您已将它们作为资源,Rails将知道在views/positions/_position.html.erb
中查找适当的部分。
最终结果应该是你永远不会编写逻辑来处理多个地方的对象持久性。这就是控制器变得复杂而形式失控的时候。它还意味着Rails和外部系统知道检索和存储对象的位置。相同的URL,相同的控制器,只是一种不同的格式。
答案 1 :(得分:1)
您可以查看这一系列的Railscast,它们讨论了REST环境中的多种关系和形式:
答案 2 :(得分:0)
我不知道RoR,所以我将在REST上生成语句。
REST和ROI将URL视为一系列名词,并使用GET,POST,PUT和DELETE等HTTP方法作为动词。此模型适用于CRUD,甚至适用于具有多个关联的模型。由于URL代表资源,因此关联对象可以表示为URL列表。
但是,如果你的系统需要更多精细动词,如验证,移动,复制,鸣喇叭,读,写等,它可能不适合REST。
答案 3 :(得分:0)
答案很长: 据我了解,Representational State Transfer只与表单和视图的实际呈现松散相关。
REST实际上与控制器和某些扩展模型有关。我们的想法是,不要试图考虑与客户进行整个对话,而是编写一个Web应用程序,以特定的,可预测的方式响应各个客户端消息。
即,如果客户端获取模型,您只需检索它,为它们格式化,发送给它们,然后忘记它。 如果客户端发布某种更新,您可以更改webapps状态以反映该情况,发送回任何响应,然后忘记它。任何未来的GET或POST都将查看新状态,但不会查看创建它的消息。
所以,实际上,应用程序是否为RESTful,实际上并不取决于模型的复杂程度,而取决于用户如何与之交互。一个应用程序意味着至少在某种程度上与客户端无关,即以数据为中心,是REST的良好候选者。某些东西严重依赖于会话,与特定用户交互,并且以流程为中心,可能不是一个很好的候选者。
另一方面,你有Rails表单助手。这些非常适合搭建脚手架,但是当你尝试以更复杂的方式使用它们时,有时会令人沮丧。
那么,你的主要问题是什么?你有关于铁轨形式助手的具体问题吗?关于rails控制器?或者特定于REST的东西?