ビジネスロジックをMVC設計のどこに配置するか？
データフォームを介してデータベースにレコードを追加する簡単なMVC Javaアプリケーションを作成しました。
私のアプリはデータを収集し、それを検証して保存します。これは、データがさまざまなユーザーからオンラインで提供されているためです。データは、ほとんどが本質的に数値です。
次に、データベース（SQLサーバー）に格納されている数値データについて、アプリで計算を実行して結果を表示します。ユーザーは計算がどのように行われるかに興味がないので、カプセル化する必要があります。ユーザーは、単純に計算されたデータ（たとえば、A列のデータからC列のデータで割ったB列のデータを差し引いたもの）のみを表示できる必要があります。同じストアドプロシージャを作成する方法は知っていますが、3層のアプリが必要です。
私はデータベースにレコードとして入れたデータを、それを計算することで処理したいと思っています。元のデータは影響を受けないままにする必要がありますが、新しいデータ（計算後）は新しいエンティティレコードとしてデータベースに保存する必要があります。
このバックグラウンド計算のコードはどこに記述すればよいですか？ルールとビジネスロジックなので、新しいJavaBeansファイルに配置する必要がありますか？
ビジネスロジックをモデルに配置し、太っているmodelsを目指します。スキニーコントローラー。
開始点として、コントローラーロジックから開始する必要があります。例：on update、コントローラはコードをmethod/serviceに転送する必要がありますdelivers =モデルへの変更。
モデルでは、アプリケーションビジネスルールまたは計算を検証できるhelper/serviceクラスを簡単に作成できます。
概念的な要約
コントローラはアプリケーションロジック用です。アプリケーションが属する「知識の領域」との対話方法に固有のロジック。
モデルはアプリケーションに依存しないロジック用。このロジックは、それが属する「知識の領域」のすべての可能なアプリケーションで有効である必要があります。
したがって、すべてのビジネスルールをモデルに配置することは論理的です。
いつものように、それはプロジェクトの複雑さに依存します。
ドメインモデルの複雑さが比較的小さい些細なアプリケーションでは、ロジックをモデルに入れて1日と呼ぶことができます。
ただし、複雑なモデルと多くのビジネスルールを備えた重要なアプリケーションの場合は、もう少し分離することをお勧めします。
モデルに複数のモデルが関係するビジネスロジックを配置すると、それらのモデル間に密結合が生じます。アプリケーションが成長し続けるにつれて、これらのモデルはgod models、知りすぎ。そして、これはすぐにテストや保守が難しい大きな混乱に変わります。したがって、その場合は、ロジックを別のレイヤーに配置することが有益です。
抽象化について決定するときは、常にアプリの複雑さと目的を考慮に入れ、過度なエンジニアリングを避けてください。ささいな/小さなアプリケーションの場合、必要以上のレイヤーを導入すると、レイヤーを減らす代わりに複雑さが増します。
Robert Martin（Uncle Bob）がこのテーマについての優れたブログ投稿を公開しています。 The Clean Architecture。
ビジネスロジックをモデル内に配置するのが最善の方法と思われるかもしれません。コントローラーはリモートWebアプリからの呼び出しを受信します。 MVC Webサービスのコントローラーが呼び出しを受け取り、実行をBLのメソッドにリダイレクトします。 現在、ビジネスロジックは「モデル」に含めることができますが、「ビジネスロジック」などの他のフォルダに配置することもできます。したがって、ビジネスロジックをどこに配置するかについて、厳格な規則はありません。
私はMVC 3.0で構築されたWebサービスを使用しており、ビジネスロジックのコンテナーはMVCです[〜＃〜]モデル[〜＃〜]。