MVC/MVP/MVPC 設計パターンでは、ビジネス ロジックをどこに配置しますか? いいえ、ASP.NET MVC Framework (別名 "Tag Soup") のことではありません。
MVC/MVPCの「Controller」や「Presenter」に入れるべきだという人もいます。しかし、モデルの一部であるべきだと考える人もいます。
どう思いますか、なぜですか?
MVC/MVP/MVPC 設計パターンでは、ビジネス ロジックをどこに配置しますか? いいえ、ASP.NET MVC Framework (別名 "Tag Soup") のことではありません。
MVC/MVPCの「Controller」や「Presenter」に入れるべきだという人もいます。しかし、モデルの一部であるべきだと考える人もいます。
どう思いますか、なぜですか?
これは私がそれを見る方法です:
コントローラーはアプリケーション ロジック用です。アプリケーションが関連する知識のドメインと対話する方法に固有のロジック。
モデルは、アプリケーションに依存しないロジック用です。つまり、関連する知識の領域のすべての可能なアプリケーションで有効な論理です。
したがって、ほぼすべてのビジネス ルールがモデルに含まれます。
ロジックを配置する場所を決定する必要があるときに、「これは常に正しいのか、それとも現在コーディングしているアプリケーションの一部だけなのか?」という質問を自問するのに役立ちます。
ASP.NET MVC アプリケーション構造のワークフローは次のようになります。
コントローラ -> サービス -> リポジトリ
上記のサービス レイヤーは、すべてのビジネス ロジックが実行される場所です。ビジネス ロジックをコントローラー レイヤーに配置すると、そのビジネス ロジックを他のコントローラーで再利用できなくなります。
コントローラーに属しているとは思いません。コントローラーに埋め込まれたら、外に出られないからです。
MVC には、別のレイヤーが間に挿入されている必要があると思います。それは、ユース ケースに対応するサービス レイヤーです。ビジネス ロジックを含み、作業単位とトランザクションを認識し、モデルと永続化オブジェクトを処理してタスクを完了します。
コントローラーには、ユースケースを満たすために必要なサービスへの参照があります。リクエストをサービスが処理できるオブジェクトにアンマーシャリングし、サービスを呼び出し、応答をマーシャリングしてビューに送り返すことを心配しています。
この配置により、コントローラー/ビューのペアがなくても、サービスは単独で使用できます。コントローラーが処理するのは、任意の方法でパッケージ化およびデプロイされたローカル オブジェクトまたはリモート オブジェクトです。
コントローラーは、ビューにより密接にバインドされるようになりました。結局のところ、デスクトップに使用するコントローラーは、Web アプリ用のコントローラーとは異なる可能性があります。
このデザインはよりサービス指向だと思います。
ビジネスロジックをドメインに入れ、ドメインを分離してください。プレゼンター -> コマンド (メッセージ コマンドは NServiceBus を使用) -> ドメイン (BC Bounded Context を使用) -> EventStore -> イベント ハンドラー -> リポジトリ (読み取りモデル) を優先しました。ロジックがドメインに適合しない場合は、サービス レイヤーを使用します。
Martin fowler、Eric Evan、Greg Young、Udi dahan の記事をお読みください。彼らは非常に明確な絵を定義しています。
Mark Nijhof が書いた記事はこちら: http://elegantcode.com/2009/11/11/cqrs-la-greg-young/
是非、モデルに入れてみてください!
もちろん、アプリやビジネス ロジックに関連するユーザー インタラクションの一部はビューに表示する必要がありますが、これはできるだけ避けてください。皮肉なことに、ユーザーが GUI で「作業」しているときはできる限り少なくし、「送信」中またはアクション リクエスト中はできる限り多くのことを行うという原則に従うことで、ユーザー エクスペリエンスと使いやすさが向上しますが、その逆ではありません。少なくとも基幹業務アプリの場合。
2か所に置くことができます。コントローラーとプレゼンテーション層。ロジックの一部をプレゼンテーション層に配置することで、システムに負荷を追加するアーキテクチャに戻るリクエストの数を制限できます。ええ、2 回コーディングする必要がありますが、応答性の高いユーザー エクスペリエンスを実現するために必要なこともあります。
私はここで言われたことがちょっと好きです ( http://www.martinhunter.co.nz/articles/MVPC.pdf )
「MVPC では、MVP モデルのプレゼンター コンポーネントは、プレゼンター (ビュー コントロール ロジック) とコントローラー (抽象目的コントロール ロジック) の 2 つのコンポーネントに分割されます。」