私は ASP.Net MVC の初心者です。多くのチュートリアルを読み、その概念を理解した後でも、ビジネス ロジックがどこに行くのかを明確に示すアプローチをまだ見ていません。
私のアプリでは、jQuery AJAX の使用が多くなります (依存関係の相互作用、検証などのさまざまな目的でコントローラーのアクションを呼び出すことになります)。ViewModel の概念を使用することは間違いありませんが、ビジネス ロジックをどこに置くべきかはまだわかりません。コントローラーやモデルを入れたくない。別のサービス層に配置する必要がありますか?
別のプロジェクトで、あなたはほとんど自分の質問に答えたと思います。
コントローラーにはなく、モデルにも絶対にありません。
編集：コントローラーはhttpcontextと高度に結合されているため、ロジックレイヤーを別のdllレイヤーに移動するのは非常に賢明です。
MVC の M は、アプリケーションで使用する情報を取得して処理するために使用されるすべてのものです。したがって、ビジネス層はその一部です。
別のクラス ライブラリを作成することから始めて、すべてのロジックをその中に入れます。クラスがかなり小さく、責任が明確である限り、別の Web サービスが必要になった場合 (別のプロジェクトがデータへのアクセスを必要とする場合) に、後で簡単にリファクタリングできます。
私は通常、第 3 のクラス ライブラリを作成し、そこにすべての定義 (サービス インターフェイスとドメイン モデル) を配置します。そうすることで、分離されたインターフェイス パターンに従い、後で実装を簡単に交換できるようになります (また、ビジネス レイヤーをテストすることもできます)。
ビジネス ロジックの一部を別の C# クラスに配置し、コントローラーで参照するだけです。これは、Web フォームの時代にコードが分離された方法です。
私が見た最も単純な例では、単純なビジネス ロジックをコントローラーに配置していますが、理想的には、ビジネス レイヤーを作成することをお勧めします。
MVC3 を使用してビジネス ロジックを分離する良い例は、ここからダウンロードできる Microsoft のプロジェクト Silk で見ることができます。このソリューションでは、ビジネス ロジックは MVC プロジェクトとは別のプロジェクトに分離されています。
このプロジェクトでは、コントローラー ロジックがビューとビュー モデル間の通信を処理するだけであることがわかります (ビジネス レイヤー モデルではなく、ビュー モデルに注意してください)。ビュー モデルには、ビューに渡される情報が含まれているだけなので、ビューのフィールドが変更されると、ビュー モデルのフィールドも変更されます。このプロジェクトはさらに、データをビューに渡すためのビュー モデルと、データを戻すためのフォーム モデルにビュー モデルを分離しますが、これは選択の問題です。
このプロジェクトでは、ビジネス ロジックにトランザクション スクリプト デザイン パターンを使用します。コントローラーは、コマンド パターン設計でインターフェイスを実装する独自のビュー モデルを使用して、ビジネス レイヤーに情報を渡します。ビジネス レイヤーから返される情報は、ビジネス レイヤー独自のビジネス モデルを介して行われます。このプロジェクトを見て、分離がどのように達成されるかをよりよく理解することを強くお勧めします.
ビジネス レイヤーの詳細については、 Wrox Enterprise .NETを参照することをお勧めします。いくつかの章では、ビジネス レイヤーを構築するためのオプションについて適切な説明が提供されています。その最初の章は、プロジェクト Silk で使用されているトランザクション パターンです。 .
お役に立てれば。