まず第一に、これは私の MVC 学習の 2 週目であり、MVC を使用してより良い Web サイト構造を設計することに非常に興味があります。
ASP.NET MVC フレームワークでは、ほとんどのビジネス ロジック コードをコントローラーではなくモデルに記述することを強くお勧めします。私の質問は、その背後にある利点は何ですか? コントローラーでデータを操作するのはよくないですか？それはより多くのリソースと時間を占有しますか?
どんなアイデアでも大歓迎です。あなたが持っている場合は、私に記事のリンクを送ってください =]
MVC のポイントは、関心の分離です。コントローラーは、データの取得元、データの形式、またはデータを取得するために適用する必要があるロジックを認識してはなりません。
モデルの仕事は、コントローラーにデータを提供することです。それ以上でもそれ以下でもありません。利点は、関心の分離です。将来ビジネス ロジックを変更する必要がある場合は、モデル内の 1 か所だけを変更するだけで済みます。
リソースと時間の観点から、データ操作がコントローラーで行われた場合、プログラムの効率が必ずしも低下するかどうかはわかりません。ただし、設計が不十分で、保守が難しい可能性があります。
MVC ウィキペディアの記事は、開始するのに適した場所です。
では、ビジネス ロジックをどこに置くのでしょうか。私はしばらくこれに取り組んできましたが、アプリのサイズと複雑さに基づいてさまざまな場所を考え出しました。
小さなアプリ: データ注釈を使用してモデルにビジネス ロジックを配置し、注釈では実現できないカスタム ルールのために IValidatableobject インターフェイスを実装します。
ミディアム アプリ: サービス オブジェクトがドメイン モデルのゲートウェイとして機能し、ビジネス ルールを検証できるサービス レイヤーを構築します。そのための優れたリソースは次のとおりです。
ビッグ アプリ: サービス レイヤーは、複雑なメッセージング フレームワークとワークフローで検証が行われるビジネス レイヤーのファサードになりました。
アプリのサイズに関係なく、モデル/ビューモデルに検証ルールを設定するのが好きです。ビジネス ルールに違反した場合とは異なり、エラー状態にあることを認識しておく必要があると思います。