最近書いたNested Resourceに関する話題をまとめておきます。

• Answer to resource, the CRUD and everything
• ネストしたリソースの問題の解決策を考えてみた
• 入れ子のリソースに関する問題について
• merb-genのresourceは何をしてくれるのか

外部サイトからのリンクバックもまとめ記事作成のための検索対象に含めたら、もっと便利になるかな。

まずはネストという言葉に関する定義の問題ですが、
諸橋さんが書いているように
、PostsコントローラはComments
コントローラを集約(aggregates)しますが、
内包(compose)する訳ではありません。

たとえば、管理画面に対応するAdminコントローラから、
Commentの削除や修正を行う場合に、AdminコントローラからCommentsコントローラを集約する事を考えると、その必要性が分かりやすいと思います。

PostsコントローラにCommentsを制御するコードを書いてしまう（内包してしまう）と、
Adminコントローラで同じ事をする必要が出来た場合に、
同じようなコードを書く必要が出てきます。

Don't Repeat Yourself!

結果として、メンテナンス性の悪いコードが出来上がります。
この事が、Postsコントローラの中でCommentsリソースを制御する
コードを書く事の問題の本質だと思います。
もちろん、あらかじめCommentsを集約する存在が
Postsしか無いと分かっている場合には問題ありません。

という事で、
続いて検索やCRUD以外の操作はどうするのかという問題について。

この問題を考えるための重要な視点として、最近のRailsやMerbでは、
リソースを制御するためのリソースコントローラと、
それ以外の制御をするための汎用コントローラの役割が分けて考えられるようになってきているという事があります。

上述の話の中で登場するコントローラを当てはめてみると、
以下のようになります。

|caption=コントローラの分類
|
|リソースコントローラ,汎用コントローラ
|
|Posts,Admin
|Comments,Dashboard

リソースコントローラとは、特定のモデルに対してCRUD（create, read, update, delete）操作を行う事に特化したコントローラです。

そう考えると、検索やCRUD以外の操作は、
汎用コントローラが行うのが自然な気がします。
例えば、ブログの記事(Posts)やコメント(Comments)
の検索を行う場合であれば、
SearchコントローラがPostsコントローラやCommentsコントローラ
を集約すればOK.
疑似コード的に表現すると、以下のような感じになります。

pre>>
Search#posts with_scope(query){ Posts#index }
Search#comments with_scope(query){ Comments#index }
<<--

この構造は２年ぐらい前にRailsで使ってみたのですが、
Railsのコントローラの実装がネストに向いていないので、
パフォーマンス上の問題に苦しみました。
Railsのコントローラは、フィルタの実行、アクションの実行だけでなく、レスポンスの作成を担っているので、ネストさせた場合に、
いったん作成したレスポンスを破棄する必要があるなど、無駄が大きいのです（Railsではお馴染みのDoubleRenderErrorが発生するのもこのせいです）

しかし今であれば、Merbを使う事によってこの問題は解決します。
Merbのコントローラはレスポンスの作成をする必要が無く、非常にシンプルなので、ネストさせてもパフォーマンスの問題はほとんどありません。

ということで、Merbを使えばみんなHappyになるよという話でした。

前回の記事の追補

前回の記事では、Aggregatorの#showで、POST, PUT, DELETEを
Aggregatedに委譲するという話を書きましたが、
例えばPostsコントローラがCommentsとTrackbacksの
２つのリソースを集約している場合に、
どちらのリソースに対する操作なのかを判別する方法を用意する必要があるので、どうやって実現するか書いておきます。

pre>>
posts/1 -> Posts#show
posts/1/comments -> Posts#show -> Comments
posts/1/trackbacks -> Posts#show -> Trackbacks
<<--

こんな感じに、posts/1/:resource に対するPOST, PUT, DELETEを、
:resourceに対応するリソースコントローラに委譲する感じですね。

ちょうどタイミング良く@maihaさんから、@yuguiさんが
近くに来てるという情報をもらったので、
@yamazさんも交えて、ネストしたリソースを扱うコントローラの問題の答えを得るべく、ミーティングをしました。

問題の定義:

モデル層で Post has_many Comment な関係にある時に、
Commentのリストとコメント投稿フォームを含むPosts#show画面（典型的な例としてはブログの一記事表示画面）から、Commentを投稿した場合に、

1. Comments#createで受け取ると、Commentのsaveに失敗した時に、Post#showを表示したいが、redirect resource(@comment.post) すると、@comment.errorsの情報がロストしてしまう。
2. Posts#create_commentなどで受け取ると、Commentリソースの処理をPostsコントローラで行う事になって責任の範囲が不明確になり、格好が悪い。

解決策

Merbベースでコンセプトを示します。
まずは、Postsコントローラの中で、以下のような包含関係を宣言するようにします。

ruby>>
class Posts < Application
has_many :comments
end

class Admin < Application
has_many :comments
end
<<--

これにより、コントローラ同士の協調関係を、コントローラ自身が知っているという事になります。
具体的にhas_manyがやることは、以下のようなbeforeフィルターをshowアクションに対してセットする事です。

ruby>>
class Posts < Application
before :only => :show do
controller = Comment.new(request)
@comment = case request.method
when "POST"; controller._dispatch(:create)
when "PUT"; controller._dispatch(:update)
when "DELETE"; controller._dispatch(:destroy)
end
end
<<--

:showアクションに対して、本来は使われない"POST", "PUT", "DELETE"
の各メソッドでのリクエストがあった場合に、Commentsコントローラに処理を回します。"GET"の場合は普通にPosts#showが行われます。
Commentsコントローラ側では、メソッドの返り値としてcommentオブジェクトを返します。

ruby>>
def create(comment)
Comment.create(comment)
end
<<--

作成に失敗した場合は、@comment.errorsにエラー情報が入っているので、
Posts#showの中から利用出来ます。

Posts#show内のComment投稿フォームは以下のような感じで、
Post#showに対してサブミットします。

html>>
<%= form_for @comment, :action => resource(@post) do %>
<%= partial "comments/form" %>
<% end =%>
<<--

コンセプトなので実際に動くかどうかまだ検証してないですが、
こんな感じで良いのではないかと。

MerbだとControllerがresponseの生成を担当していないので、
コントローラをまたいだ処理のネストが高速に行えます。
Railsの場合は、個々のアクションの実行がresponseの生成を伴うので、
この方法だとオーバヘッドが大きくて難しいかもしれません。