MVCは作っているうちに破綻する（１／２）

MVCとはアプリケーションの内部のコンポーネントを、Model（データ） View（表示） Controller（ロジック）という３つのレイヤーに分けて考える思想です。例えばJava Webアプリケーションでは Model=JavaBean、View=JSP、Controller=Servlet などと言われたりします。

まあWebアプリを作ったことのある人であれば「こんなに簡単に分けられねーよ」ということを身をもって知っていると思います。実際に作ってみると
　▽　Model＝JavaBean + 業務ロジック
　▽　View＝JSP＋表示ロジック
　▽　Controller＝制御＋業務ロジック
と何となく曖昧に、ロジックとデータと表示が渾然一体になってしまうものです。
もちろん、例えば Actionクラスに一切業務ロジックを持ち込まず「これはコントローラだ」と気合いで分けてしまうことは可能です。しかし、それは単にロジックをファイルに分割したに過ぎない。実際のところアプリケーションは各所にロジックやデータを持つものであり、MVCという区分はあくまで便宜的なものなのです。

つまり、MVCは単なる方針として最初にざっくりと区別しておくだけに留め、それよりもロジックやJavaBeanをキレイに分けてデザインすることに注力した方が結果的にはよい設計になる、ということです。ざっくりと言ってもMとVとCの分類だけではいまいちなので、例えば

▽ Model1（データに近い系）
⇒ DB（DAO）
⇒ JavaBean (※1)
⇒ データ処理系汎用的ユーティリティ（型変換、エンコード／デコード処理など）
(※1) DAOとJavaBeanは分けた方がいいです。

▽ Model2（業務に近い系）
⇒ 業務ロジック
⇒ 業務系汎用ユーティリティ
⇒ 表示制御ロジック ※2

▽ Controller1（フレームワーク系）
⇒ 普通はフレームワークが準備してますね。StrutsのActionクラスとかSpringのControllerとか

▽ Controller2（業務に近い系）
⇒ 業務ロジックに近いController（Validationとか、ロジックによる画面の振り分けとか）
⇒ 表示制御ロジック ※2
(※2)は後述

という感じで区別するのが私の好みです。この分類でパッケージを分けてしまってもよいでしょう。
私見ではデザインの美しさは、JunitによるUTの容易さによって評価され得ると思います。つまりメソッド単位あるいはインターフェース単位で完全に独立しているのが望ましい。あまりMVCにこだわってもしょうがない。どうせMVCという枠組みは曖昧かつゴタゴタになるんだから。

（続く）
.