MVC(ASP.NET MVC)バンド3層アーキテクチャはどのように連携できますか?
-
27-09-2019 - |
質問
私はデザインドキュメントを書いており、私のチームの人々はASP.NET WebformからASP.NET MVCへの動きを喜んで行います。これは素晴らしいことですが、3層(データレイヤー、ビジネスレイヤー、プレゼンテーションレイヤー)のアーキテクチャでMVC WorkSwithを理解するのは難しいです。モデル、ビュー、コントローラーはプレゼンテーションレイヤーの一部であると言えますか?モデルはビジネスレイヤーの一部ですか?
簡単に言えば、MVCと3層のアーキテクチャはどのように連携することができますか?助けてくれてありがとう!
解決
ASP.NET MVCはプレゼンテーションレイヤーにあると考えています。使用する「モデル」クラスは、実際にビューモデルであり、ビューで必要なデータ構造を説明しています。すべてのビジネスロジックとデータアクセスは、MVCモデルとコントローラーとは別に留まる必要があります。
また、MVCの一般的な「ベストプラクティス」は、コントローラーコードを可能な限りシンプルに保つことです。これは、通常、ヘビーリフティングを処理するビジネスレイヤーにアプリケーションサービスの一部を導入することを意味します。
他のヒント
プレゼンテーションレイヤーはあなたのビューです。
データレイヤーはモデルです(リポジトリパターンを見ることをお勧めします)。
ビジネス層はそれが何であるかのままです。
コントローラーは、オブジェクトがロードされたときに機能のためにビジネスレイヤーを呼び出すことができます。または、特定のViewModelが要求された場合、モデルは機能のためにビジネスレイヤーを呼び出すことができますが、それ以外の場合は同じままです。
コントローラーには、広大なビジネスロジックが含まれてはなりません。独自の自己完結型DLLに入れてください。
これはかなり主観的です。 あなたのチームにとって理にかなっていることをしてください。
MVCは非常に柔軟であり、すべての言語でMVCフレームワークがほとんどなく、同じように行われます。 .NETスペースでも。 fubumvc、spring.net、およびMS MVCはすべて、わずかに異なる方法で物事を行います。
まず第一に、MVCに変更する必要はありません。
しかし、質問するには、MVCパターンのモデルは、ビジネス上の問題を表すあらゆる種類のクラスです。 MVCフレームワークには、ソリューションを提案する方法としてフォルダーがあります。そのため、モデルクラスを配置できますが、必要ではありません。さまざまなプロジェクトを作成できるため、ビジネスの問題を解決し、モデルです。したがって、ここでは、インスタンテ用に他のパターンを定義できます。リポジトリパターンを使用して、NhibernateまたはEntityフレームワークを使用して実装できます。
ビューは、ユーザーに情報を表示および受信するための単なるWebページです。
コントローラーは、アプリケーションの入り口であり、リクエストを受信し、必要なモデルを呼び出し、指定されたビューにリダイレクトするクラスです。
私が助けてくれたことを願っています。
MVCを備えたN層は正常に機能します。堅実な原則と他のいくつかの原則に従うだけで、アプリケーションをゆるく結合してまとまりやすくすることができます。
MVC 3の本を読んで、PluralSight.comのビデオを見ることがあなたの最大のリソースだと思います。 「チームのために働くことをやる」と一緒に行くことはできません。ジョニーとティミーという名前のワークアソシエイトが、「あなたのチームのために働く」短期的な締め切りのラッシュで、それを正しく /善 /スマートにしないという理由だけで、コントローラーに多くのロジックを入れたいと言っている場合。
私はインターネット上で非常に多くの悪い記事を見つけたので、何人が悲惨な暗い道を導いているのか怖いです。幸せな道をたどります。 Artのような意見にはStackoverflowを使用しますが、MSDNの記事、MVC Books、およびPluralSight.comを確認してください
私はそれが単なるウィキペディアのリンクであることを知っていますが、いくつかの情報があります ここ N層とMVCアーキテクチャについて。
「層」は展開単位であり、MVCの「レイヤー」はコード内の責任の論理的な分離です。