Restful让我束手束脚

在Rails中View+Controller+Helper是紧耦合的，Controller中的方法与相关目录下的view template一一对应；Model+Migration+DB是紧耦合的。这2大块之间是松耦合的。

这2块的内部组织方式是完全不同的：

对于Model层，我们通常会对业务进行OO分析，提取出一些名词和名词之间的关系，然后把他们映射成Model，这个过程比较直观，是相对细粒度的。

对于View层，我们要考虑的是用户怎么用着舒服，为了用户的方便，页面可能很简单，也可能很复杂，一个页面可能包含多个Form，一个Controller也可能调用多个Model的功能对view提供支持，它是对Model的一个全新的组织，是相对粗粒度的。我们有可能把几个相互关联的Model组织到同一个View+Controller里面集中的向用户展示。

 如果没有Restful，一切工作的很好，URL我爱怎么写就怎么写，全看个人习惯。但是现在Restful来了，一句 map.resources 给了我们7个URL。看看这个

map.resources :articles

 

问题是这句话假定我们有一个名为ArticlesController的控制器，这无形中把ArticlesController的功能限制为对某一项资源的CRUD。

<!----><!----> <!---->

想象一下这个场景，我要录入一篇Article，然后查询系统中已有的author（作者），把这篇artile与某个author关联起来。也就是在Add an article页面还要添加search author的功能，OK,问题来了，search_author这个方法我放哪？ArtilesController吗？你得自己添加map.connect，这似乎违反了restful，ArtilesController要处理另外一个资源的CRUD。AuthorsController吗？AuthorsController怎么关联到别的Controller的view? Controller是不是一定要和View一一对应？

 

<!----><!----><!---->

我觉得应该是我对restful的理解还不够深入，但至少现在我觉得restful给我带来严重的限制。

 

你说的这个需求和Restful还真的不矛盾。

search author的功能放在AuthorsController里。

Add an article的时候，通过ajax方式请求author功能就可以了。

正解
根本就不应该有“Search Author”这么个按钮，一边输入一边就搜索了

我不太同意楼上的看法，这也是我对restful困惑的主要的地方。
如果按照restful，那就是一个controller里面包含某一项资源的CRUD，那就相当于人工的把controller和Model一一对应起来了，如果这样的话，controller和Model之间还是松耦合的吗？我的看法是Model层和Controller+View的组织方式应该是完全不同的，或者说Controller+View应该如何来组织完全取决于展示逻辑并且独立于Model。

我觉得restful只是一个写url的规范，原来只是简单的url，现在则是动词+url，他不应该影响到我的代码的组织。
Controller应该是个矮胖子，说它矮的意思是他应该包含尽量少的业务逻辑，把业务逻辑尽量的往Model推。说他胖的意思是他应该完全按照展示逻辑来组织。页面简单，Controller也简单，页面复杂，Controller也可以跨越或调用多个Model的功能。

 

把searches抽象为一个资源如何

 

你把尽可能多的东西抽象成资源（CRUD），那么Controller就很精简了

@世说新语

我觉得这里你要正确理解一项资源的概念，这里的资源不是不可分割的对象。

比如，我们可以在创建文章的时候加入一个作者，作者作为文章的一个相关资源

a = Article.new(:title=>'How to study ROR', :subtitle=>'what is important')
a.authors.build(:name=>'SOMEONE')
a.save

我们也可以创建作者的时候，输入他写的一篇文章

a = Author.new(:name=>'SOMEONE')
a.articles.build(:title=>'How to study ROR', :subtitle=>'what is important')
a.save

 

呵呵，这让我想到了元数据和数据元。

map.resources :articles 就是几行map.connect语句的简写,用map.resources :articles, :collection => {:search_by_author => :get}进行扩展,rails书或rails REST cheatsheet上都有写.
如果你觉得search应该作为一个资源,就建立一个新的controller并用resources声明到routes里.

 

这是针对我的问题的一个比较现实的解决方案，我现在用的就是这个。但是这个方案也有问题，它背后隐含着依然是Controller与Model一一对应的组织方式，在一个Controller中对另一种Model的访问被作为特例来处理。不是我认同的Controller与Model相互独立的组织方式。

 

另外关于把Searches抽象为资源的方式已经超出了我的理解范围，把的动词作为资源的做法我还无法接受。

 

究竟哪种是最佳实践？在DocumentsController中写search_author方法？还是所有涉及Author访问（包括相关的view templates）的都必须在AuthorsController中？假如我的系统里针对author除了search之外没有别的CRUD的操作，难道我也一定要建一个AuthorsController专门处理这个search_author请求吗？如果一个页面涉及到多个Model（因此会由多个partial template组成），那页面代码是不是要被割裂在不同的View目录下，Views/document，Views/author . . . . . 。2种代码的组织方法都行得通，但我相信还是有优劣之分的。

 

rails网站上最新的15分钟创建blog视频采用的是我不太认同方式，Post和comment两个model，对post的CRUD都在PostsController中进行，对commmet的CRUD都在CommentsController中进行。这个“半官方”的视频让我对自己的观点不太自信。希望大家多多发言，把这个事整明白。

细读了楼主的贴,发现问题很简单,foxgst和gigix说的很清楚.

首先,rails对REST的支持是在routes之上进行了简单的包装,跟传统MVC并不冲突. controller和model并没有绑定. 从rails的实现角度,一个资源指一个controller,跟model一点关系都没有.

搜索author列表这个功能,在创建article的页面里用到了,除去这个使用上下文,该功能在业务上是不是有独立性?我认为是有的. 放到AuthorsController里很正常,action取名为index/list/search/all都可以.

至于articles/new.rhtml中如何使用这个action,可以使用ajax+json的方式. 我以前发过个贴,说RJS对于REST是种反模式,我个人在任何时候都不主张使用RJS.

gigix是说,像google suggest那样,输入前几个字符时就自动弹出可选项,更人性化.

liuqiang是说抽象成Searchable, 比如你把author/article都用全文检索做了索引,这样抽象可能更容易组织代码,实现上稍微方便一些.

另外,你的例子很怪异,create article时还能选author. 正常应该从session里取吧