これは私の個人的な見解です。他の人は違うものを持っているかもしれないと確信しています。あなたがこの質問をしているので、私はあなたが議論に開かれていることを願っています. そうでなければ、多くの人々が非常に強い意見を持っており、それらを変える可能性が低いため、このトピックは宗教的な議論のようなものであるため、私は気にしませんでした.
個人的には、ストアド プロシージャはビジネス ロジックを記述するためのものではないと思います。これらは、データ アクセス ロジックの記述に使用する必要があります。動的検索などの高価なクエリを最適化したい場合にのみ、ストアド プロシージャを使用しますが、他には何も使用しません。ドメイン モデルにロジックがある場合は、パフォーマンスがわずかに低下しますが、ほとんどの状況では目立ちません。
ストアド プロシージャでビジネス ロジックを記述することを強く支持する理由の 1 つは、ストアド プロシージャを変更することで一部のロジックを簡単に変更できるからです。しかし、適切なテストを行わずに、デプロイされたアプリケーションのビジネス ロジックを実際に変更する必要があります。うっかりミスをしてしまったらどうなる？継続的なビルドでは、展開を行うことはそれほど大したことではありません。プロの開発者として、そのリスクを冒すべきではないと思います。
ロジックをストアド プロシージャで記述することにした場合、オブジェクト指向の概念をすべて放棄し、おそらく 10 年前に記述した手続き型コードを記述することになります。C# 言語は現在、長い道のりを歩んでおり、ビジネス ロジックであるアプリケーションの中心部でこれらの新しい言語機能を使用することはできません。また、コードをリファクタリングするための Visual Studio 機能、高度で簡単なデバッグ機能なども失います。
ソースコードに表示されないため、トリガーを使用するという考えも好きではありません。チームの新しい人がしばらくしてから新しい機能を追加しようとしていて、トリガーが存在することを知らなければ、間違ったロジックを書く可能性があると想像してください。
アプリケーションに複雑なビジネス ロジックが含まれている場合 (ほとんどのアプリケーションがそうであると確信しています)、エンティティのプロパティだけでなくロジックも含むドメイン モデルが必要です。そうしないと、貧血データモデルと呼ばれるアンチパターンに陥ることになります。
ストアド プロシージャにロジックがある場合、単体テストを記述してビジネス ロジックをテストすることはできません。
また、サイトが本当に成功した場合、ストアド プロシージャにビジネス ロジックを複数のサーバーに配置することはできません。
また、ストアド プロシージャにすべてのロジックがある場合、エンティティ フレームワークと LINQ のすべての強力な機能を使用することにはなりません。それが取ろうとしているアプローチである場合、実際にはORMマッパーは必要ありません。
これは私があなたのプロジェクトに推奨するものです。データベースが既にある場合でも、エンティティ フレームワークのコード ファースト アプローチを引き続き使用できます。EF コード ファースト リバース エンジニア パワー ツールをダウンロードして、コード ファースト コードを自動生成することができます。これは 1 回限りのことであり、さらに変更がある場合は、データベースに直接行って、それに応じてコードの最初のコードを更新することができます。Fluent API は最初は少し混乱しますが、生成されたコードから簡単に学ぶことができます。
コントローラーからデータ コンテキストにアクセスしないでください。すべてのデータ アクセス ロジックを含むリポジトリ レイヤーを用意します。コントローラーからリポジトリにアクセスできます。(これにより、リポジトリをモックしてコードの単体テストを行うことができます)。asp.net サイトには、リポジトリ パターンの使用方法に関するビデオ チュートリアルが多数あります。
ドメイン モデルは、エンティティ フレームワークから生成されたエンティティになります。これらのモデルにビジネス ロジックを含めるようにしてください。ドメイン モデル パターンに慣れるには少し時間がかかります。しかし、慣れてくるとそのメリットを実感できるようになります。
お役に立てれば。