MVC - それは単なる 3 層モデルですか?

Question

mvc について研究し始めたばかりですが、まだ理解できていません。私が収集したものから、それは 3 層ソリューションの実装のように見えます。つまり、モデルは DAL、コントローラーはビジネス ロジック層、およびビューはプレゼンテーション層に対応します。

ここで私は基地から大きく外れていますか？

Answer 1

モデルを単なるデータ アクセス層として扱うことには注意してください。これは単純化しすぎており、コントローラー層に多くのコードを追加することになります。そのコードをさらにモデルに組み込み、データベースの永続化をモデルの内部コードの一部のみにする方がよいでしょう。私は MVC について次のように考えるのが好きです。

• コントローラ：入力を処理し、どのモデルとどのビューをインスタンス化するかを決定します
• ビュー：申請データの提示
• モデル：アプリケーションの他のすべてのロジック (DAL を含むがこれに限定されない)

これは基本的には ページコントローラー パターン。

これについての別の考え方は次のとおりです。Web アプリをコマンドライン アプリやデスクトップ GUI アプリなどの別のプラットフォームに移植する必要があるとします。アプリケーション ロジックのどの部分を再利用する必要がありますか?アプリを別のプラットフォームに移植すると、入力と出力の両方の実装を変更する必要があるため、コントローラーとビューも変更されます。変更する必要のないコードはモデルに実装する必要があります。

関心事の分離が正しく行われていれば、モデル、ビュー、コントローラーが最小限に結合され、他にあまり影響を与えることなく 1 つの実装を変更できます。モデルを変更し、コントローラーまたはビューで多くのコードを書き直すことになる場合は、これらのレイヤーが適切に分離されていない可能性があります。およびその逆。

マーティン・ファウラーについて読む 貧血ドメインモデル アンチパターンか ドメイン駆動設計を迅速に実行 他の視点を得るために。

私のものも見てください 2008年のブログ これは、アクティブ レコード パターンを非難する人々に応えて書いたものです。良いコメントや議論が得られました。

Answer 2

ソートの。それはこのようになります：

最も一般的に、今日使用されるパターンは、次のとおりです。

Database -> DAL -> BLL -> Controller -> View Model -> UI

ここで、

DAL == Data Access Layer (aka ORM, Object-Relational mapper)
BLL == Business Logic Layer

あなたは常にすべての層を必要としないことに注意してください。アプリが十分に小さい場合BLLとビューモデルは、例えば、オプションのことができます。

あなたは NerdDinnerチュートリアルをチェックアウトする必要があります。それは、これらの概念のすべてを説明しを単一の参照

Answer 3

あなたはMVCに新しいしている場合は、ここでいくつかの素晴らしい解説ます：

私のそばに誰もがちょうどASPを取得していません。 NET MVCですか

Answer 4

短いメモ、あなたはコントローラは、ビジネス層であること（必要はありません）ことができると言うとき、あなたは正しい、とビューは、プレゼンテーション層である。

データ層/操作するデータを取得する層であるのに対し、

ただしモデルは、データを含む（実装に応じて）オブジェクトです。