Cake PHP MVC Model Collected

MVCモデル2008-02-05 (火) 設計 | 発展 | コントローラ | ビュー | モデル 今回はちょっと難しい話です。 Webアプリケーションの構造として、MVCモデル(※1)というものがあります。 MVCモデルとは、M(Model)-V(View)-C(Controller)の3つのコンポーネントから構成する手法で、Jakarta Strutsでその地位を確固たるものにしてきています。Struts以外でも、Ruby on Railsなどでも取り入れられています。もちろん、cakePHPもMVCモデルを採用しています。 MVCモデルについては、様々な解説がありますが、大雑把な部分はWikiPediaの記事が分かり易いでしょうか。 http://ja.wikipedia.org/wiki/Model_View_Controller MVCの利点としては、データ操作、表示、それら2つの制御と分離して記述することが可能となり、各コンポーネントごとの独立性が高まり、修正に対する影響範囲の限定、または、開発者の特性に合わせて作業分担が容易となることがあげられます。 急にこんな記事を書きたくなったのには理由があって、cakePHPのGoogleグループでの議論で以下の質問があったためです。 http://groups.google.com/group/cake-php/browse_thread/thread/72536712313ebb6b/61324fed0f934849?lnk=gst&q=MVC#61324fed0f934849 デザインパターンをはじめとしたソフトウェア工学の道具は、非常に強力である面もあるのですが、一方では、お題目としては立派なものを掲げていても、実際に利用するのは、大変だったり、その対象に適しているかの判断が重要だったりすることがあります。 MVCモデルはある程度こなれてきた技術であり、また、cakePHP自体がMVCモデルに基づいて開発することを前提としたフレームワークなので、MVCの基礎を知っていれば、利用することは比較的難しくありません。 しかし、上記のGoogleグループの話題のように、データに対する加工については、MVCの理論的に言えば、モデルの仕事ですが、cakePHPで開発していくと、どちらかというとコントローラで実装してしまいがちです。 MVCモデルに基づくといっても、MVCモデルに完全に忠実に習うことが決してよいとはいえませんので、コントローラでデータを加工することが悪いわけではありません。 大事なことは、 いかによいコードを書くか? ですから。 とはいえ、開発していく中でこの処理はモデルで、この処理はコントローラで・・・とごちゃごちゃになってしまうのは最悪ですので、そこに何か目安となる指標を与えられないかと思います。 フレームワークを用いる一つの理由は、誰が開発してもある程度一定の水準のものを開発したいというものもありますので、そのような指標があれば、cakePHPを使っていく上で、有用なのではないかなと思っています。 そこで、Webアプリケーションの処理をきちんと考えてみました。 クライアント側 情報の表示 ユーザ入力 サーバ側 処理内容の決定 ユーザ入力のチェック データの読み込み データの加工 データの保存 データに基づく判断 データを集めた処理 出力の決定 おおよそ、こんな感じかなと思います。ここでは、データは意味のある単位でまとまったデータを想定しています。もっと露骨な言い方をすると、テーブルの1行分のようなイメージです。 このうち、間違いなく分類できるものを分類していくと、 モデル データの読み込み データの保存 ビュー 情報の表示 ユーザ入力 コントローラ 処理内容の決定 データに基づく判断 出力の決定 というところでしょう。 というわけで、以下のものは一概にきめられないと思います。 ユーザ入力のチェック データの加工 データを集めた処理 順に考えていきます。 ユーザ入力のチェック ユーザ入力といっても、2通りの場合があると考えています。 1つは、データそのものとなる場合、つまり、ユーザ登録フォームから入力を受け付けるような場合です。この場合のチェックはモデルが担当すべきだと思っています。 もう一つは、データとして保存しない場合、例えば、一覧から検索する際の検索条件のような場合です。この場合は、方針として2つ考えられます。 もし、idだけを受け取って検索するようなシンプルな場合は、Controller中で実装してしまうのが分かり易いと思います。しかし、入力の内容が多い、あるいは、同様のチェックが色々な場面で利用されるといった場合には、DBに保存しなかったとしても、対応するモデルを作成し、そのモデルの中で実装するのがスマートだと思います。 データの加工 データの加工は基本的にはモデルで行うべきだと思います。 例えばですが、学年データを含んでいて内部的には数字で管理しているが、ユーザには1年生、2年生、・・・、M1、M2、D1、D2、D3というように表示させたい場合には、ユーザ入力の2年生という文字列を数字の2に変換する。逆に5という数字をM1に変換するといった処理は、モデルに記述することにより、一貫性がとりやすくなります。 また、初期値の設定のようなものもモデルで担当するのが分かり易いと思います。実際、cakePHPでは、保存時にモデルの処理中でレコードの作成日時(created)や、更新日時(modified)を自動で更新してくれます。 これの例外としては、 保存する手順によって処理を変える必要がある場合だと思っています。 データ中にあるフラグがあり、一般向けの画面から追加された場合はそのフラグをONにしてい保存したいが、管理側からの追加された場合はOFFにしたいといった場合があるかと思います。この場合も、モデル側にそれぞれの保存の機能を追加することも可能ではあると思いますが、それをしてしまうと、モデルの実装がコントローラ側の実装に依存してしまいよくないと思っています。 このようなフラグ程度の場合については、コントローラ側でデータを加工した方が分かり易いはずです。 データを集めた処理 最後が、データを集めた処理です。 簡単にこの状況が想定されるのは、統計的な処理です。 これは、モデルかコントローラか判断に迷うところですが、個人的にはコントローラに実装する方がよいと思っています。一つのモデルは一種類のデータを処理すると考えるのが分かりやすいですので、複数種類のデータを扱うことは避けたいためです。 では、単一データの統計処理ならばいいのか?という疑問があるかと思いますが、答はYESに近いですが、findCountやqueryを使ってデータを取得すれば十分な話だと思うので、実装という意味では、やはりコントローラになるといえるでしょう。 では、コントローラにすると決めたから、すべてまるく収まるかというとそうではない場合があります。それは、統計的な処理が複数の場面で必要になることがあるからです。 画面によって、1ヶ月ごと、1年ごとと表示を変えたい場合などです。この場合は、次のように考えています。 処理の規模が小さくて、かつ、1つのactionでしか利用されない場合は、そのaction内に記述する。 処理の規模が大きい、または、複数のactionで利用される場合は、コントローラクラス中のprivate関数に記述する。 複数のコントローラで共有したい場合には、componentとして実装する。 いかがでしょうか? 個人的な見解ですが、これで今のところ対応するようにしています。 もし、「こういった分類も必要だ!」ですとか、「この分類は、こう記述した方がよい」などのご意見などありましたら、意見を聞かせてください。 ※1:デザインパターンの世界においてはMVCモデル2という言い方が正確です。

 

Copy from:

http://www.fr-soft.com/cake/archives/category/%e3%83%93%e3%83%a5%e3%83%bc

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: