MVCアプリケーションのビジネスロジックレイヤー
私のASP MVCアプリケーションでは、別のビジネスレイヤーを追加することにし、プロパティのみを持つモデルを作成しました。
Save to db、get from dbのような他のすべての機能は、この新しいビジネスレイヤーで行われます。したがって、コントローラーはこのビジネスレイヤーとさまざまな操作のモデルを呼び出します。このようなデザインへの良いアプローチですか？
さまざまなアクションにはいくつかのモデルが必要になるため、この目的にはモデルを使用しないことにしました。 （たとえば、編集用と作成用の2つ）
それは私にとって非常に賢明な決断のように思えます。 MVCはプレゼンテーションパターンであるため、ビジネスロジックと永続化操作はアプリケーションのUIレイヤーには配置されません。
理想的には、MVCモデルは、ビューによってレンダリングされるために提示しているデータだけです。これは、必ずしも同等のドメインエンティティと同じであるとは限りません。たとえば、モデルはUI検証属性でタグ付けする必要があり、複数選択の値を含めることができ、日付、通貨値などの表示用に変換されたデータを含めることができます。または言語翻訳。このため、MVCのMをビジネスエンティティと区別し、エンティティからコントローラーロジックのモデルにマップすることは賢明です。コントローラーアクションは、基になるビジネスロジックレイヤーを呼び出し、レンダリングのためにモデルに返されたデータをマーシャリングすることほど複雑なことをする必要はありません。
モデルによってドメインモデルを意味する場合、それはビジネスロジックが存在する場所です。ビジネスロジックからそれを取り除くと、一般に「貧血ドメインモデル」と呼ばれるものが得られます（ www.martinfowler.com/bliki/AnemicDomainModel.html を参照）。
要点は次のとおりです。あなたの会社は、特定のビジネスドメインについて独自の認識を持っています。エンティティには特定の用語があり、エンティティに対する特定の動作とエンティティ間の相互作用を規定しています。そのようなものをモデル化する最良の方法は、状態と（ビジネス）動作の両方を持つドメインエンティティクラスを実際に作成することです。通常はドメインエンティティの一部である動作を吸収するあらゆる種類のサービスを作成するのではありません。
モデルがプレーンな検索でDBに保存する場合は、個別のModelクラスは必要ありません。オーバーヘッドになります。
データを操作し、クラスのカスタム表現を形成してビューに表示する場合は、アプローチを使用するのが最適です。さらに、将来的にモデルがさまざまなソースから入力されることが予想される場合、アプローチは完璧なケースになります。
それは完全にあなたのアプリケーション設計に依存します
すでに述べたように、MVCは単なるプレゼンテーションパターンであり、ビジネスレイヤーを持つことに問題はありません。ただし、これらのレイヤーは非常に薄く、ロジックがないため、コントローラーから直接そのレイヤーを呼び出さないでください。
実際にできるパターンは複数あります。Pattern3が言及しているようです here が要件に合っています。