自身をYuichirouと名乗る謎の男が文字通り「つれずれなるままに」書くよくわからん日記。
検索サイトから来た方、こんなページでゴメンナサイ。下にあるフォームに検索ワードを入れて検索すると、情報が得られるかも。
なお、タイトルに打ち間違いはありません。
1504 | 01 | 02 | 03 |
2003 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 |
2009年10月13日
■はてなインターンのときに描いた私なりのMVCモデルのイメージを公開しちゃうよ!

最近「Life is beautiful: O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」」「Life is beautiful: Ruby on Railsの「えせMVC」の弊害」が話題になっているけど、これ読んで1年前にはてなサマーインターンで学んたMVCモデルの(自分なりの)イメージをメモに描いたことを思い出したので、1年ぶりに引っぱり出してみた。
この図は私なりの認識であって、これとは違うモデルを主張する人もいると思うけど、多くのWAFはこのようなモデルでうまく解釈できるので、1年経った今も私はとりあえずこの図のようなモデルを頭に描いています。
なお図中の固有名詞ですが、「Ridge」ははてなスタッフのカンファレンス講演などでたびたび出てきている、はてなの自社製WAFです。また「MoCo」はCPANで公開もされているはてなの自社製O/Rマッパー「DBIx::MoCo」のことで、「Template-Toolkit」はPerl界隈では有名なテンプレートエンジンです。
図の丸で囲んだ「IN」と「OUT」は見た通りインプットとアウトプットで、矢印はデータの流れを表しています。また四角のサイズは各部分で記述するコード量をやや誇張しつつ表していて、例えばControllerはなるべく小さく、単にModelとViewの組み合わせを決めて橋渡しするだけであるべき、ということを表しています。
ここでポイントだと私が思っているのはModelの構造で、実はModelは(少なくとも)2層に分けられると考えています。つまりModelにはO/Rマッパー(図では「MoCo」)だけではなく、各ウェブアプリのコード(ビジネスロジック)も属するのです。Life is beautifulの中島さんが主張しているのもココの部分のことで、O/Rマッパー(この図では「MoCo」、RoRではActiveRecord)それだけをModelと呼ぶことを問題視しているものと理解できます。
ちなみに今年2月に発表された「デブサミ2009 はてなの開発戦略」では、上の図で「(各アプリのコード)」と書いた部分をApplication*1という新たな要素として見た「MVACモデル」を提案したり、それをModelに含めつつ2つに割り、「データソース層」「サービス層」「アプリケーション層」の3層構造ではてなブックマークのModel部を設計していることが紹介されています。(持っている人はWEB+DB PRESS Vol.49 特集2「はてなブックマーク構築ノウハウ大公開」、特にp.55が参考になると思います)
(とりあえずこの辺で筆を下ろします*2置きます)



