AI-VC-MC概論
頭のAはアプリのAなんで、好みによってシステムのSにしてもらってもなんら問題ないんですけどね。
で、本題。
通常のアプリって、Controller上でのModelとViewとのやりとりでどうこうしてるのが普通かな、と、思うんですけど、場合によってはView用二次Controllerというかそういうのとか、Model用二次Controller的なものとかがあったりする場合もありますよね、と。
特にこういう作りになりやすいのが、外向けに作ってるライブラリかなーという感触。
正直それってアプリとインターフェイスがあって、それぞれのコントローラにリクエスト送ってるだけじゃねぇかと言われればそれだけなんですけどね。
結局、実操管理するのと描画管理するのと処理管理するのってやっぱり違う訳で、ControllerとView・Modelとの連携が密にできないパターンで考えると表題にあるような面倒な階層分けになってくることがよくあるんですよね、と。
そういう意味では、Application Interface - Model Controller - View Controllerという形で作っておけばライブラリ化したとしても、ついでにいうと移植したとしても可用性を落とさず動作できるんじゃねぇかな、とか思いますよね、と。
要するに何が言いたいかって、それぞれが何を担保するのかというのを明確化するならこういう作りにならざるを得ないんじゃねぇのって話なんですよね。
Interfaceが担保すべきは『どういう動作要求があるのか』ということだし、Viewが担保すべきなのは『描画要求が来たときに正しい表示をする』ことだし、Modelが担保すべきなのは『要求に応じたデータを入出力する』ことだと思ってます。
言ってしまえばそれだけとも言えるんですよね。
はっきり言うと、一部のControllerに処理を乗せすぎてるアプリというのが非常に多い。
処理が多いのが悪というよりは、処理が多くなるとそのクラスが担保すべき部分が曖昧になるのがアウトだと言いたいんですよね。
やけに肥大化したControllerがある場合のだいたいが、一つのControllerで賄おうとする範囲が広すぎるパターンだったりしますし。
担保外の動作をするクラスというのがそもそも害悪というか、なんというか。
こういう考え方をしていくと、ModelとUtilityって別のものだ、ということになってくる気はするんですけどね。
というか、VeiwUtility（LayoutUtility）とModelUtilityで分類できるだろうとも思う。
この辺りは考えれば考えるほど多層化していくのがなんとも言い難い部分ではあるんですけどね。
操作を担保する。
描画を担保する。
データ入出力を担保する。
そういう切り分けで考えれば表題みたいな形になるんじゃねぇかなと思うというだけの話ではあるんですけど。
実際View寄りControllerとModel寄りControllerって分類は可能な気もしますしね。
