これからはじめるRuby on Rails

2010年10月6日(水)
川尻 剛

仮に、プロセスを中心にRailsアプリケーションを設計すると、どうなるのか。以下で検証してみましょう。

例えば、「商品を販売する」という機能を実現する場合、「販売する」という動詞に注目して、処理フローを設計します。しかし、サービス・レイヤーを定義しようと思っても、RailsではValidationがActiveRecordの責務となっているので、ついコントローラに処理を配置しがちです。

結果として、図1に示すような、再利用できないロジックになってしまいます。または、トランザクションを実行してしまう、複雑なコントローラになってしまいます。こういうケースが、非常に多いのが現実です。

図1: コントローラにロジックを実装した例

解決策として、図2に示すように、販売を、名詞と見なしてテーブル・ビューと対応付けた上で、振る舞いを考えた方が良いでしょう。この場合、販売コントローラは、リクエストを処理して販売のインスタンスを作成するだけのシンプルな構成となります。販売処理の再利用も容易になります。

図2: ActiveRecordにロジックを分離した例

以上、従来の設計と、アクティブ・レコードのアンマッチについて説明しました。

それでは、Railsには、どのような設計が向いているのでしょうか。個人的には、ER(Entity Relationship)図に振る舞いを加えたようなものからスタートするのが良いのではないか、と考えています(最もRailsらしいのは、設計前に実装して反復しながら詰めていく方法です)。

なお、先述した、「処理の内容を顧客に説明するのが困難である」という問題は、「アプリケーションに期待する振る舞いを細かく定義する」という方向に進みつつあるようです。

株式会社日立ソリューションズ

技術開発本部 Rubyセンタ所属
1977年生まれ。入社後、自社フレームワークの開発を経てRIAの調査などに関わる。
最近は「お客様とチームがより幸せなるマネジメント」を目標としてプロジェクトマネジメントを勉強中。著書に「Java開発者のためのAjax実践開発入門」(共著)など。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています