MVCにおけるModelについて

ドメイン（領域）の分離はアプリケーション開発において非常に重要なファクターです。 とりわけWeb界隈を中心に、ドメイン分離手法として広く用いられているのがMVC（Model-View-Controller）です。 ※Modelからのイベント通知（Observerパターン）を用いないようにしたMVCをMVC2と呼ぶらしいです。 Web界隈でのMVCはほとんどがMVC2ですね。 [MVC と MVC2 について改めて考えてみる - スタジオ・アルカナ技術ブログ](http://www.s-arcana.co.jp/tech/2011/07/mvc-mvc2.html) このMVC2とMVPやMVVMなどを含めて**（広義の）MVC**とも呼ぶみたいです。ややこしいですね。 ブログやツイッターやプライベートで何度か話題にしていますが、MVCはその本来の使い方からずれて用いられることも少なくありません。 特にModelの位置づけが人によってとらえ方がまちまちです。上記のとおりMVCを広義にとらえてもModelは（イベント通知する/しない以外は）同じ構造になるはずです。 また、著名なフレームワークでもModelという名前をフレームワークの局所的に取り入れたり、 Modelという名前が無いにしろユーザーがこぞってModelという名前を使ったりすることで、利用者を混乱させるものも少なくありません。 **ルビー鉄道**や**背骨**などが有名どころでしょうか。 そこで、ここではフレームワークを適用した結果ありがちなMVCのModelと、本来のMVCのModelとを比較してみます。 # ありがちなModel よくあるのが**xxModelを継承してModelを作成する**というものです。 フレームワークによってModelの基底クラスが用意されている場合、 そのサブクラスを作成することで、フレームワークの提供する機能を利用することが出来ます。 例えばRuby on railsでは、ActionRecord::Baseクラスを継承することで、 オブジェクトをDBにストアーするといった機能が使用できるようになります。 このActionRecord::Baseのサブクラスをmodelsパッケージに入れる為、 ActionRecord::Baseのサブクラス=Modelという誤解が生まれてしまうわけですね。 ※とはいえ、modelsにActionRecordのサブクラス以外を入れてはいけないという決まりは無い事を書いている時に気づきました また、上記と関連して**get-set以外のメソッドを含まない**という事もありますね。 # 本来のModel 上記のありがちなMVCを（Controller等も含めて）指摘したスライドとして有名なものがこちら。 [やはりお前らのMVCは間違っている](http://www.slideshare.net/MugeSo/mvc-14469802) 本来のModelの考え方はよりシンプルです。 Modelは、**画面描画に関する動作を含まないオブジェクト**のことです。 データベースにストアーするものはModelかもしれませんが、**それ以外もModelに成り得ます**。 逆に、データベースにストアーするものでも、**HTMLのキャッシュといったものはModelでは無い**かもしれません。（かえってややこしいでしょうか） Modelの変化を**イベントで通知**してもいいですし、上位から**ポーリングを受け付け**（MVC2）ても構いません。 **POJO、POCOが望ましい**ですが、 フレームワークの恩恵を受けるために提供されたスーパークラスを持つ事も出来ます。 因みに、**副作用**（引数とフィールド変数以外の要因で動作が変わること）**を含むことも出来ます**。 ※副作用も切り出したい場合は、[ドメイン駆動設計](http://amzn.to/10AD4px)の適用をおすすめします。 # まとめ MVCはドメイン分離として現実的で妥当な概念ですが、 誤って用いることで本来のメリットを受けることが出来ず、かえってアプリケーションの複雑化を招いてしまうこともあります。 MVCに限らず、それぞれのツールが持つ本来の意味をとらえ、 そのメリットを最大限生かして納得のいくアプリケーションを開発していきたいですね。