■ MVC / MVP
http://www.atmarkit.co.jp/fdotnet/vblab/bizappbasic02/bizappbasic02_01.htmlより... ■業務アプリの構造を... [1] 論理的な3つの層に分ける（物理的ではなく、概念的） [2] それぞれの層にやるべき作業（＝役割）を定義する
イメージ
[ユーザ] <=> プレゼンテーション層 <=> ビジネスロジック層 <=> データアクセス層 <=> [DB]
メリット
それぞれの層が役割に応じた処理を行うため... [1] 可読性が増す（どこでどんな処理が行われているのかが分かりやすい） [2] 用件などの変更に強い
プレゼンテーション層
以下の処理などをビジネス・ロジック層に受け渡す処理 ■例 * ページの表示 + エラー・メッセージの表示 + ビジネスロジック層から受け取った結果 など... * ページ間の遷移 * ユーザーが入力した内容 * 入力値の妥当性チェック（バリデーション） + 金額フィールドに数値以外が入っていないか + 必要なフィールドに値が入っているか など... => 下記【業務上の論理的なデータチェック】とのすみ分けは開発者ごとに認識が変わりそうなので意識合わせやルール決めが相当難しそう。
補足
* ユーザーの要望や別のユーザー(顧客・企業)が変わったことにより、変化する可能性が高い層 => このため、3層に分ける意味(利点)の一つであると思う。 => できる限り、ユーザーや要望に依存しない処理や共通箇所は、ビジネスロジック層以降に記述し、プレゼンテーション層とを上手く分離することが重要だと思う
ビジネスロジック層
* 業務にかかわる処理を記述 * 業務上のルールを記述する層 * 業務アプリにおける肝になる層 ■例 * 申請などにおける承認フロー * 業務上の論理的なデータチェック + ユーザの入金がなければ、出荷を実施しない など...
補足
* 業務ルールの変更などによって変化する層 => 業務上で変化するもの、しないものを適切に見極めて設計することが重要
データ・アクセス層
* 以下のようにデータ関連する処理 + データ取得 + データ保存 * 一般的には、データベース操作に関わる処理
三層に分けるヒント
三層にきっちり分け、上記のメリットの恩恵を受けるには、きちんと設計されている必要がある。 そこで、その設計のヒントを記述する。 * 変更の可能性が低いものは、変更に強い設計をする必要はない => 一般的に変更に強い構造にしてしまうと、不必要に複雑度が上がってしまう
MVC パターン
* Controller がユーザーからの入力イベントを受け取る
MVP パターン
* View がユーザーからの入力イベントを受け取り、処理を Presenter に委譲する
注意
WEB三層モデル(三層構造)
* MVCとWEB三層モデル（三層構造）は別物。http://ja.wikipedia.org/wiki/%E5%A4%9A%E5%B1%A4%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3#.E4.B8.89.E5.B1.A4.E3.82.A2.E3.83.BC.E3.82.AD.E3.83.86.E3.82.AF.E3.83.81.E3.83.A3
より抜粋 三層は一本の直線で表される。 それに対して MVC では 3つがそれぞれ相互に通信するため、三角形を形成している。 * WEB三層モデルについては、関連記事を参照のことhttp://blogs.yahoo.co.jp/dk521123/34667365.html
参考資料
http://www.atmarkit.co.jp/fdotnet/vblab/bizappbasic01/bizappbasic01_01.htmlhttp://www.atmarkit.co.jp/fdotnet/vblab/bizappbasic01/bizappbasic01_02.html
http://www.atmarkit.co.jp/fdotnet/vblab/bizappbasic02/bizappbasic02_02.html
