私は設計ドキュメントを作成しており、チームのメンバーは ASP.NET WebForm から ASP.NET MVC への移行を進んで行っています。これは素晴らしいことですが、MVC が 3 層 (データ層、ビジネス層、およびプレゼンテーション層) アーキテクチャでどのように機能するかを理解するのに苦労しています。モデル、ビュー、およびコントローラーはプレゼンテーション層の一部であると言えますか? モデルはビジネス層の一部ですか?
簡単に言えば、MVC と 3 層アーキテクチャはどのように連携できるのでしょうか? 助けてくれてありがとう！
ASP.Net MVC はプレゼンテーション層にあると考えています。使用する「モデル」クラスは実際にはビュー モデルであり、ビューに必要なデータ構造を記述します。すべてのビジネス ロジックとデータ アクセスは、MVC モデルとコントローラーから分離しておく必要があります。
また、MVC の一般的な「ベスト プラクティス」は、コントローラーのコードをできるだけシンプルに保つことです。これは通常、アプリケーション サービスのいくつかを、重労働を処理するビジネス レイヤーに導入することを意味します。
プレゼンテーション レイヤーはビューです。
データ層はモデルです (リポジトリ パターンを参照することをお勧めします)。
ビジネスレイヤーはそのままです。
Controller は、オブジェクトが読み込まれるときに機能のためにビジネス レイヤーを呼び出すことができます。または、特定の ViewModel が要求されたときにモデルが機能のためにビジネス レイヤーを呼び出すことができますが、それ以外は同じままです。
コントローラーには拡張性の高いビジネス ロジックを含めるべきではありません。これを独自の自己完結型 DLL に配置します。
MVC を使用した N 層は問題なく動作します。SOLID の原則と他のいくつかの原則に従うだけで、アプリケーションを疎結合でまとまりのあるものに保つことができます。
MVC 3 に関する書籍を読んだり、pluralsight.com のビデオを視聴したりすることが最大のリソースだと思います。「チームに役立つことをする」ということはできません。ジョニーとティミーという名前の仕事仲間が、短期間の締め切りラッシュで「チームのために働く」という理由だけで、コントローラーにたくさんのロジックを入れたいとしたら、それは正しい/良い/スマートにはなりません。
インターネット上で非常に多くの悪い記事を見つけたので、どれだけ多くの人々が悲惨な暗い道に導かれているのか恐ろしい. 幸せな道をたどってください。アートのような意見にはstackoverflowを使用しますが、msdnの記事、mvcの本、およびpluralsight.comで確認してください
これはかなり主観的です。 チームにとって意味のあることを行います。
MVC は非常に柔軟で、すべての言語で同じように機能する MVC フレームワークはほとんどありません。.net スペースでも。FubuMVC、Spring.net、および MS MVC はすべて、わずかに異なる方法で処理を行います。
まず第一に、理由だけで MVC に変更する必要はありません... 機能しているものがあれば、変更する必要はないと思います。
しかし、あなたの質問には、MVC パターンのモデルは、ビジネス上の問題を表すあらゆる種類のクラスであり、あらゆる種類の計算、ビジネス ルール、またはデータ アクセス クラスである可能性があります。MVC フレームワークには、ソリューションを提案する方法としてフォルダーがあるため、そこにモデル クラスを配置できますが、その必要はありません。さまざまなプロジェクトを作成して、ビジネス上の問題を解決できます。それがモデルです。したがって、ここでは、インスタントのために他のパターンを定義できます。Repository パターンを使用して、NHibernate または Entity Framework を使用して実装できます。
ビューは、ユーザーとの間で情報を表示および受信する単なる Web ページです。
コントローラーはアプリケーションへの入り口であり、リクエストを受け取り、必要なモデルを呼び出し、指定されたビューにリダイレクトするクラスです。
私が助けてくれることを願っています。
「層」は展開の単位ですが、MVC の「層」はコード内の責任の論理的な分離です。
ウィキペディアのリンクであることはわかっていますが、n 層と MVC アーキテクチャに関する情報がここにあります。