個人的には、元のビジネス ロジック コードを抽出する必要がある場合、または複雑なビジネス ロジック コードを別途クラス ライブラリに実装する必要があると思います。
MVC は主にビュー、モデル、ユーザー コントロールの分離を解決します。実際のビジネスシナリオでは、複数テーブルの結合クエリやトランザクションプロセス処理など、より複雑な論理処理が含まれる場合があります。これらの複雑で比較的独立しており、ビューに依存しないビジネス ロジック コードを別個のクラス ライブラリに抽出して、外部インターフェイスを提供できます。依存関係注入または MVC での直接参照を通じて呼び出されます。 MVC の M はドメイン モデルの役割を果たしているだけですが、これはより適切かもしれません。

この質問が行われているのを見たとき、「バカ、バカ、何のJB質問をしているんだ？」と言いたくなりましたが、よく考えてみると、ここでは何があっても寛容でなければならないと感じました。あなたに聞きたいのですが、あなたが基づいているビジネス ロジックや基盤は何ですか?なぜこれを行うのでしょうか?これを行うことの利点は何だと思いますか?これを基に、私たちはあなたの考えを分析して答えることができます。そうでない場合、ほとんどの人は、特にテクノロジー関連の仕事に就いている人は、理由を知りたがる場合が多く、それは理不尽だと考えるでしょう。叱るよ。残念ながら、ここでは 1 つだけ触れておきます。他の 3 つの層をモデルに含めると、それはモデルとは呼ばれず、MVC とも呼ばれなくなります。それを説明しないでください。

はは、投稿者の表現力に問題があるようですね

プロジェクト内の他の 3 つのレイヤーをモデルに統合します。このように階層化することに何の意味がありますか?

これを行うのは非科学的です。MVC は他のものを分離することです。

ああ、これを行うと、なぜ MVC を使用する必要がなくなります...

あなたは宇宙人です。 。 。 。

2B、まだ無視してるのですが、はっきり聞いてもらえますか？

mvcの概念が理解できます