Ad Network

あわせて読みたい

  • あわせて読みたい

« デザイン・パターンとは何か | Main | Cloud Computing考:Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた »

「RESTful MVC」なアーキテクチャの話

Architecture

 最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。

 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。

 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON(XMLでもかまわない)をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく(ずる=本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事)。

 クライアント側でJavaScriptが実行できないようなブラウザーに対しては、サーバー側にControllerをおいてView TemplateとModelの結合を行って生成したHTMLを返す。JavaScriptが実行できるブラウザーに対しては、あえてサーバー側にはControllerをおかず(もしくは最小限のものにとどめ)、JavaScriptで記述されたControllerをブラウザーに送り込み、HTMLで記述されたView TemplateとJSONの形で送られて来たデータとの結合はクライアント側で行う(先日のjQBinder参照)。

 こんな風に作る一番の利点は、Modelへのインターフェイス作りをさぼることが絶対にできなくなること。ブラウザーのタイプによって二つの異なるView/Controllerペアとやりとりをしなければならないのでインターフェイスの明確な定義は必須だし、Statelessで非同期なインターフェイスなので、データの整合性を守るための複数のテーブルにまたがったトランザクションは絶対にModel側でしなければならないことはプロジェクトに関わる全員に自明となる。

 また、Modelはデータベースやサーバー側のハードコアなプログラミングに慣れたエンジニアが担当し、View/Controllerは見た目やユーザーインターフェイスにこだわるエンジニアが担当する、など作業分担もしやすくなる。

 それに加えて、Modelのインターフェイスが特定の言語に依存しないため、ModelはJavaで(サーバー側の)ControllerはPHPでとか、各モジュールのモックアップをRailsでアジャイルに作ってから本来の言語で本実装をする、などのテクニックが使えるのも利点だ。

 もちろん、これもデザイン・パターンの一つでしかないので、どんな場合にも適用できる話ではないが、少なくとも私が関わっているプロジェクトのほとんどすべてにこのアーキテクチャが適用できそうだな、と思っている今日この頃である。

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c4f9853ef0120a5ef5566970b

Listed below are links to weblogs that reference 「RESTful MVC」なアーキテクチャの話:

Comments

もり

本題から外れますが、図がきれいで素敵ですね。
どんなツールで描かれているのでしょうか?

Satoshi Nakajima

>どんなツールで描かれているのでしょうか?

PowerPointです(Microsoft Office 2008 for Mac)。

takezaki

触発されて書いてみました。長文すみません。

http://blog.virtual-tech.net/2009/10/mvc.html

dotcom

まったく関係ないんですが、ご存知かもしれませんが、newsweekに以下の記事が出てましたのでお知らせします。

iPhoneアプリ開発者の貧乏度


http://newsweekjapan.jp/stories/business/2009/10/post-625.php

MY

規模が大きくなった時に、スケールする際、はどのように考えてますかね?
ビジネスロジックが乗ってるサーバーへ対してのアクセスが集中するようなイメージですが。

またJavaで言うHttpSessionや、ログイン認証系、一時的に持っておく情報などは、
どのように管理しようと思ってます?
パラメータ持ちまわすとなると、結構フロント側の設計に影響あるし、
JavaScriptでその辺りをとなると辛そうですが。
モバイルを意識してCookie使わずに実装するイメージになってるのかな?と推測したのですが。


うにら

その図で言えばAdvanced Browser側のJSとHTML以外をCMSベースにしてAdvanced BrowserとCMSをフィードやREST、XML-RPC等でやりとりすれば
ビジネスロジックやコンテンツ管理を最小限に出来る上に(用途や利用するCMSにもよりますが)
CMSの基本機能+プラグイン導入でモバイルブラウザやサーチエンジンにも容易に対応できるので
面白そうなんて妄想してたことがあったのを思い出しました

えーじ

mixiアプリやgooホームで使われているOpenSocialガジェットのアーキテクチャにかなり似ていますね。
http://www.opensocial.org/

DQNEO

大変勉強になりました。

業務システムなどでこのパターンを適用すると、View/ControllerはExcelやAccessで実装する、なんてことができますね。

ModelがXMLやCSVを吐き出して、Excel/VBAがそれをパースする、みたいな感じで。

Post a comment

This weblog only allows comments from registered users. To comment, please Sign In.