某草草2017-05-16 17:07:52
個人的には、元のビジネス ロジック コードを抽出する必要がある場合、または複雑なビジネス ロジック コードを別途クラス ライブラリに実装する必要があると思います。
MVC は主にビュー、モデル、ユーザー コントロールの分離を解決します。実際のビジネスシナリオでは、複数テーブルの結合クエリやトランザクションプロセス処理など、より複雑な論理処理が含まれる場合があります。これらの複雑で比較的独立しており、ビューに依存しないビジネス ロジック コードを別個のクラス ライブラリに抽出して、外部インターフェイスを提供できます。依存関係注入または MVC での直接参照を通じて呼び出されます。 MVC の M はドメイン モデルの役割を果たしているだけですが、これはより適切かもしれません。
某草草2017-05-16 17:07:52
この質問が行われているのを見たとき、「バカ、バカ、何のJB質問をしているんだ？」と言いたくなりましたが、よく考えてみると、ここでは何があっても寛容でなければならないと感じました。あなたに聞きたいのですが、あなたが基づいているビジネス ロジックや基盤は何ですか?なぜこれを行うのでしょうか?これを行うことの利点は何だと思いますか?これを基に、私たちはあなたの考えを分析して答えることができます。そうでない場合、ほとんどの人は、特にテクノロジー関連の仕事に就いている人は、理由を知りたがる場合が多く、それは理不尽だと考えるでしょう。叱るよ。残念ながら、ここでは 1 つだけ触れておきます。他の 3 つの層をモデルに含めると、それはモデルとは呼ばれず、MVC とも呼ばれなくなります。それを説明しないでください。
