Spring MVCフレームワークのどこにビジネスロジックを入れますか？
私はそれに慣れていないので、Spring MVCのどこにビジネスロジックを置くべきかわかりません。私は何をすべきかについての手がかりを持っていますが、Spring MVCの知識が不足しているため、どこから始めればいいのかわかりません。また、これに関する優れたチュートリアルや、ビジネスロジックが含まれるSpring MVC Webアプリケーションの完全なサンプルを入手できる場所を誰かが知っているかどうかを尋ねたいと思います。とにかく、私が話していたビジネスロジックは、データベース処理に関するすべてです:)
@Controllerクラスは、MVCのCとして機能します。 Spring MVCの実際のコントローラーはDispatchServletであり、特定の@Controllerクラスを使用してURL要求を処理することに注意してください。
@Serviceクラスは、サービスレイヤーに使用する必要があります。 ここにビジネスロジックを配置する必要があります。
@Repositoryクラスは、データアクセスレイヤーに使用する必要があります。ここに、挿入、更新、削除、選択というCRUDロジックを配置する必要があります。
@Service、@RepositoryおよびエンティティクラスはMVCのMになります。 JSPおよびその他のビューテクノロジ（JSP、Thymeleafなど）は、MVCのVに準拠します。
@Controllerクラスは、インターフェースを介して@Serviceクラスにのみアクセスできる必要があります。同様に、@Serviceクラスは、他の@Serviceクラスと、インターフェースを介した@Repositoryクラスの特定のセットにのみアクセスできる必要があります。
多くの人は、ビジネスロジックをサービス層に追加することをお勧めします。個人的には、特にテストを開始するとき、それは素晴らしいアイデアではないことがわかります：永続性とビジネスロジックを同時に処理するか、すべてをあざ笑う必要があるかもしれません。
結論を出す前にこの記事を読むことをお勧めします。 Spring Webアプリケーションの最大の欠陥
再開すると、ビジネスロジックをモデルレイヤーに移動し、サービスメソッドを簡素化するという考え方になります。
一般的に、ビジネスロジックはサービスレイヤーに入ります。ただし、JSRアノテーションを使用して、基本的な検証ルールをpojoに配置できます。
Spring MVCアプリの場合、http要求を処理するコントローラーと、ビジネスモデルを表すpojoであるドメインレイヤーがあります。多くの場合、永続層（DAO）があります。自明ではないロジックを支援するために、サービスレイヤーを用意することもできます。
データベース処理に関するコメントは意味がありません。ビジネスルールは、データの保存と直交しています。データベースの処理は、永続化レイヤーで行う必要があります。