この文章、結構インチキ入ってますが、お許しを。
今更ながらMVCとかまとめてみした。
・MVC Model、View、Controllerの3つの領域に分ける。Smalltalk80で確立。
・MVC2 JavaServerPages の MVCアークテクチャーの Type2 のこと。ビジネスロジックはEJBで実装することになっている。Model=EJBなどJavaBean、View=JSP、Controller=Servlet。
・BCE Boundary、Control、Entityのこと。MVCとの比較で書くと、ModelはControl（制御）、Entity（永続データ管理）に分けられ、View、Controller は Boundary に相当する。
MVC自体が元々GUIを想定して考えられたパターンだから、MVC2が実際の開発現場だとちょっと微妙なことになっているのかも（JavaBeanにどこまでロジックもたせてますか？）。個人的にはBCEのほうがしっくりくるかな。
実際のWebアプリの開発現場だと画面と内部処理を分離するのは自然とそうなるんだよね。
画面はHTMLだったりして、UI設計のセンスに長けた人間、場合によってはデザイナーとかが作ればいいと思うから、やっていくうちに「テンプレートを使おう」とかってなるじゃないですが、ほぼ。
内部処理をロジック制御とデータ管理の部分の分離だけども、泥臭くSQL文などを書くのにしんどくなってきて、「フィルター条件与えればデータを引っ張ってこれる」だったり、「パラメータを与えればテーブルを更新してくれる」くらいのことは共通化したいなぁ、って思って、DAO的なライブラリを記述するじゃない。
なんていうかな、知らず知らずのうちにMVCとかBCEっぽくなるんだよね、きっと。
レイヤ単位で作業の分割を考えるとこんな感じでしょうか。
データ中心の発想っぽいかもしれませんが。
・画面(View、Boundary)屋さん ･･･ DreamWeaver とかでHTMLをバリバリ書く人。簡単な制御タグとかちょっとぐらい知っているといいかも。場合によってはFlashとかも。
・ロジック制御（Controller、Cotrol）屋さん ･･･ 実際のロジックを書く人か？ただしデータ管理はあまりしない。SQL文も書かない。
・データ管理(Entity、Model)屋さん ･･･ DBMS次第だけど、場合によって、SQL文をバリバリ書く人。データ管理ばかり。一昔前ならPL/SQLのプロシージャー担当？
() の中は厳密な定義とは違うと思うけど･･･Modelはビジネスロジックの処理をやるわけだし･･･、まぁ、それは置いておき。
ロジック制御屋さんとデータ管理屋さんの作業分担が微妙になるのかな。
ロ「○○を渡したら××のデータ配列が返って来るメソッド作ってよ」
デ「既に△△ってメソッドあるじゃない、それ使ってよ」
ロ「え、そっちで作ってよ。ラップさせるだけだからいいでしょ？」
とか
ロ「○○ってデータを処理するメソッド作ってよ」
デ「××と△△を組み合わせれば出来るよ」
ロ「他の箇所でも使うんだから、そっちにもたせて共通化させたほうがいいよ」
みたいな。
ただ、うまくいけば自分の作業領域に専念することが出来るので開発効率が上がるのでしょう。
っていうかね、自分UI設計のセンスないんで、HTMLのコーディング含め、画面はやはりデザイナーがバリバリ書いてくれればいいと思います。
FYI:
ＵＭＬによるアーキテクチャパターン
[oosquareml:02404]
Re: 分散環境での MVC について
あとこれも。
「StrutsのMVCってどんなんだっけ？」とふと気になったので。
Struts、オープン・ソースMVC実装
