3

Open Session In View (OSIV)フィルターまたは Spring に付属のインターセプターを使用することを考えています。これは、開発者としての私にとって便利な方法のようです。それがあなたの推奨事項である場合、フィルターまたはインターセプターの使用をお勧めしますか?またその理由は?

また、 HibernateTemplateとどのように混合するのか、メソッドを@Transactional(readOnly = true)などとしてマークする機能を失い、よりきめ細かいトランザクション制御を取得する機能を失うのではないかと考えています。

この種のソリューションを Hibernate と Spring を使用して 3 層アーキテクチャに統合する方法について、何らかのベスト プラクティスはありますか (プレゼンテーションに Wicket を使用するという私の決定はあまり重要ではないと思います)。

OSIV を使用すると、少なくとも遅延読み込みの例外に遭遇することはありません。一方、トランザクションは、ビューでもコミットされていないため、コミットできるようになるまで長く存続します。

4

2 に答える 2

4

それは本当に個人的な好みの問題です。

個人的には、サービス層にトランザクション境界を設けるのが好きです。SOA について考え始めると、サービスへのすべての呼び出しは独立している必要があります。ビュー レイヤーが 2 つの異なるサービスを呼び出さなければならない場合 (これは既にコードの匂いであると主張できます)、これらの 2 つのサービスは互いに独立して動作し、異なるトランザクション構成を持つことができます。 services は、サービスの外部で変更が発生しないようにするのにも役立ちます。

OTOH サービスで何をするかについてもう少し考える必要があります (遅延読み込み、共通のトランザクション性が必要な場合は同じサービス メソッドでの機能のグループ化など...)。

遅延読み込みエラーを減らすのに役立つパターンの 1 つは、サービス層の外側で値オブジェクトを使用することです。サービスは常に必要なすべてのデータをロードし、それを VO にコピーする必要があります。永続オブジェクトとビュー レイヤーの間の直接的なマッピングは失われますが (つまり、より多くのコードを記述する必要があります)、明確さが得られることに気付くかもしれません ...

編集:決定はトレードオフに基づいて行われるので、少なくとも部分的には個人的な好みの問題だと思います. サービス層でのトランザクションは、私にとってはよりクリーンに感じられます (より SOA に似ており、ロジックは明らかにサービス層に制限されており、異なる呼び出しは明確に分離されています...)。このアプローチの問題は、VO を使用して解決できる LazyLoadingExceptions です。VO が永続オブジェクトの単なるコピーである場合、はい、それは明らかに DRY 原則の違反です。データベース ビューを使用するように VO を使用する場合、VO は永続オブジェクトを単純化したものです。書くコードは増えますが、デザインがより明確になります。いくつかの認証スキームをプラグインする必要がある場合に特に役立ちます: 特定のフィールドが特定のロールにのみ表示される場合、

于 2009-02-10T10:09:21.130 に答える
2

OSIV を使用すると、少なくとも遅延読み込みの例外に遭遇することはありません

それは真実ではありません。実際、悪名高い LazyInitializationException に遭遇するのは非常に簡単です。オブジェクトをロードし、ビューの後にその属性を読み取ろうとすると、構成に応じて LIE が取得されます。

于 2009-02-10T09:53:38.750 に答える