データフォームを介してデータベースにレコードを追加する簡単なMVC Javaアプリケーションを作成しました。

私のアプリはデータを収集し、検証して保存します。これは、データがさまざまなユーザーからオンラインで調達されているためです。データは本質的にほとんど数値です。

データベース（SQLサーバー）に格納されている数値データで、計算を実行して結果を表示するアプリを作成します。ユーザーは計算の実行方法に関心がないため、カプセル化する必要があります。ユーザーは、単純な計算データ（たとえば、A列データからB列データをC列データで除算したもの）のみを表示できる必要があります。同じストアドプロシージャを記述する方法は知っていますが、3層アプリが必要です。

データベースにレコードとして入れて、計算を実行して処理したデータが必要です。元のデータは影響を受けないまま、計算後の新しいデータは新しいエンティティレコードとしてデータベースに保存する必要があります。

このバックグラウンド計算用のコードはどこに書くべきですか？ルールとビジネスロジックなので、新しいJavaBeansファイルに入れる必要がありますか？

ビジネスロジックは中に置かれるべきモデル、そして私たちは脂肪を目指すべきであるモデルとスキニーのコントローラ。

開始点として、コントローラーロジックから開始する必要があります。例：updateの場合、コントローラーは、モデルに変更を配信するメソッド/サービスにコードを送信する必要があります。

モデルでは、アプリケーションのビジネスルールまたは計算を検証できるヘルパー/サービスクラスを簡単に作成できます。

概念的な要約

• コントローラーはアプリケーションロジック用です。アプリケーションが所属する「知識の領域」と対話する方法に固有のロジック。

• このモデルは、アプリケーションに依存しないロジック用です。このロジックは、それが属する「知識の領域」のすべての可能なアプリケーションで有効でなければなりません。

• したがって、すべてのビジネスルールをモデルに配置することは論理的です。

いつものように、それはプロジェクトの複雑さに依存します。

ドメインモデルの複雑さが比較的小さい単純なアプリケーションでは、モデルにロジックを入れて1日で呼び出すことができます。

ただし、複雑なモデルと多数のビジネスルールを使用する自明でないアプリケーションの場合は、物事をもう少し分離する方が適切です。

モデルに複数のモデルを含むビジネスロジックを配置すると、それらのモデル間に密結合が生じます。アプリケーションが成長し続けるにつれて、これらのモデルはになりgod modelsすぎて、あまりにも多くを知るようになります。そして、これはすぐにテストと保守が難しい大きな混乱に変わります。そのため、この場合、ロジックを別のレイヤーに配置することが有益です。

抽象化を決定するときは、常にアプリの複雑さと目的を考慮し、過剰なエンジニアリングを避けてください。些細な/小さなアプリケーションの場合、必要以上のレイヤーを導入すると、レイヤーを減らす代わりに複雑さが増します。

Robert Martin（Uncle Bob）には、このテーマに関する優れたブログ投稿があります：The Clean Architecture。

モデル内にビジネスロジックを配置すると、最適な方法に聞こえるかもしれません。コントローラーは、リモートWebアプリから呼び出しを受信します。MVC Webサービスのコントローラーは呼び出しを受け取り、実行をBLのメソッドにリダイレクトします。現在、ビジネスロジックは「モデル」に含めることができますが、「ビジネスロジック」など、他のフォルダーに配置することもできます。そのため、ビジネスロジックをどこに配置するかについての厳格なルールはありません。

MVC 3.0で構築されたWebサービスを使用しており、ビジネスロジックのコンテナーはMVC MODELです。