Spring MVCのコントローラを@Transactionalにしない方がいい理由とは？

私の観点では、これは私がこれまで見た中で最高のデザインです。Spring MVC で同じ設計を再現しようとすると、遅延ロードとトランザクションの問題で悪夢を見ることになり、毎回同じ答えが返ってきました。

あなたの設立された回答を事前にありがとうございました

どのように解決するのですか？

TLDR : これは、アプリケーションのサービス層だけが、データベース/ビジネストランザクションの範囲を特定するために必要なロジックを持つためです。設計上、コントローラーと永続化層はトランザクションのスコープを知ることはできませんし、知るべきではありません。

コントローラは @Transactional にすることもできますが、実際にはサービス層のみをトランザクションにすることが一般的な推奨事項です（永続化層もトランザクションにすべきではありません）。

この理由は、技術的な実現可能性ではなく、関心事の分離です。コントローラの責任は、パラメータリクエストを取得し、1つまたは複数のサービスメソッドを呼び出し、結果をレスポンスにまとめ、クライアントに送り返すことです。

つまり、コントローラはリクエスト実行の調整役と、ドメインデータをクライアントが消費できる形式（DTOなど）に変換する機能を持つのです。

ビジネスロジックはサービス層に存在し、永続化層はデータベースとの間でデータを取得/保存するだけです。

口座振替では、他方が入金されている場合のみ口座が引き落とされるなど、ビジネスロジックを含むサービス層のみが銀行口座振替のトランザクションの範囲を実際に知ることができます。

永続化レイヤーはどのようなトランザクションであるかを知ることができません、例えば、メソッド customerDao.saveAddress . このメソッドは常に別のトランザクションで実行されるべきなのでしょうか。時にはそれは別のトランザクションで実行されるべきですし、時には saveCustomer が動作した場合のみデータを保存する、などです。

同じことがコントローラにも当てはまります。 saveCustomer と saveErrorMessages が同じトランザクションに入るのですか？あなたは、顧客を保存し、それが失敗した場合、いくつかのエラーメッセージを保存し、データベースに保存したいエラーメッセージを含むすべてをロールバックするのではなく、適切なエラーメッセージをクライアントに返すようにしたいと思うかもしれません。

非トランザクションコントローラでは、サービス層から返されるメソッドは、セッションが終了しているため、切り離されたエンティティを返します。これは正常な動作で、解決策としては OpenSessionInView を使用するか、コントローラが必要とする結果を熱心に取得するクエリを実行することです。

とはいえ、コントローラをトランザクションにすることは罪ではありません。