0

アプリケーションでASP.NETMVCを使用しています。アプリケーションを3層アーキテクチャに分割しました。1)データアクセス層(Entity Frameworkを使用)、2)アプリケーション/ビジネス層、3)プレゼンテーション層(ASP.NET MVC)。

プレゼンテーション層でMVCフレームワークを使用しているため、ビジネスロジックについて混乱しています。ビジネスロジックをMVCパターンのどこに配置するかを知る必要があります。言い換えれば、中間層をどこから呼び出す必要があるかを言うことができます。モデルからですか、それともコントローラーからですか?

コントローラからビジネスロジックを呼び出すと、モデルは役に立たないようです。そうでなければ、モデルからビジネスロジックを呼び出すと、ビジネスオブジェクトがモデルとマップされてからモデルがコントローラーに渡されるため、システムに不要な入札が行われたように見えます。モデルは、DTOが実行していることを正確に実行します。

どんな助けでもありがたいです

4

2 に答える 2

4

ASP.NET MVCレイヤーまたはティアには、ビジネスロジックもビジネスモデルも含まれていません。MinMVCはUIモデルの略であり、アプリケーションコアのモデルではなく、MVC(および他のMV*パターンも)一般的にUIの問題を分離するためのパターンです。コントローラーからビジネスレイヤー(BL)にメッセージを送信(呼び出し)し、データを集約し、結果を作成またはUIモデルにマッピングして、表示に渡す必要があります。UIモデルはBLモデルについて何も知らないはずです。この区別により、アプリケーションのレイヤーが緩く結合されます。

言い換えれば、中間層をどこから呼び出す必要があるかを言うことができます。モデルからですか、それともコントローラーからですか?

間違いなくコントローラーから。依存関係を注入し、Actionメソッドから呼び出します。ASP.NET MVCは、コントローラーへの注入依存性の多くのメカニズムを提供し、NInject、StructureMap、およびその他のIoCコンテナーとうまく統合します。

MVCのコンポーネント間の依存関係を以下に示します

ここに画像の説明を入力してください

写真は、GUIアーキテクチャに関するMartinのFowlerの記事からの抜粋です。ちなみに、MVCとMVPに関する非常に良い読み物です。

また、Pluralsightには、デザインパターンをカバーするソフトウェアプラクティスに関する一連のビデオがあります。MVVMとMVPの定義から多くのことを学びました。

この資料を読むことで、パターン自体だけでなく、パターンがアプリケーション環境にどのように適合し、それと相互作用するかについても理解を深めることができます。

于 2013-01-17T11:24:02.003 に答える
0

これは、要件に基づいて行う必要のある純粋な設計/アーキテクチャの決定です。

他のサービス/アプリケーションをサポートするためにアプリケーションをスケールアップする場合は、コントローラー/モデルにビジネスロジックを記述しないことをお勧めします。あなたはそれをビジネス/アプリケーション層で書くことができます。これは、将来的にアーキテクチャをスケールアップするのに役立ちます。モバイルアプリケーション用のRESTfulサービスを作成する場合は、既存のビジネス/アプリケーション層を再利用するためのラッパーとしてサービスを作成できます。

また、ドメイン駆動設計をご覧ください。EricEvansの本は読む価値があります。

http://dddsample.sourceforge.net/architecture.html

于 2013-01-17T12:33:20.977 に答える