完成したばかりのプロジェクトでは、分散トランザクションを機能させる作業を行っていました。
これは、JBoss の Arjuna Transaction Manager と Spring の宣言型トランザクション境界を使用して実装しました。
リクエスト シーケンスは次のようになります。
browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO
これが意味することは、保護されたサーブレットにサービスを提供する WAR と、SLSB にサービスを提供する EAR があるということです。
SLSB には、Spring アプリケーション コンテキストをブートストラップするための静的イニシャライザ ブロックがありました。
テクノロジの混在は好きではありませんが、物理的に異なる場所に配置できるプレゼンテーション層とビジネス層の分離は好きです。
Spring を使用するときに、他の人が層を分離するために何を提案しているのか知りたいですか?
ファサードであるSLSBのためだけにEJB3アプリサーバーを必要とすることは、私にとって努力する価値がないように思われます。それを削除して、サーブレットをSpringで直接動作させることができなかった理由はありません。ContextLoaderListenerをWARに追加してApplicationContextをロードし、次にWebApplicationContextUtilsを追加してそれを取得できます。あるいは、サーブレット自体が許可する以上のことを行う必要がある場合は、SpringMVC、Struts、またはその他のWebテクノロジーを使用できます。
非常に典型的なアプローチは、Web 層、サービス層、および DAO 層を定義し、サービス層にトランザクション セマンティクスを付加することです。たとえば、サービス層は、@Transactional アノテーションが付けられた一連の POJO である場合があります。Web 層は、Spring Web MVC コントローラーである場合があります。このアプローチでは、Web 層は本質的にサービス層を HTTP に適合させています。ここでは分離が良好で、SLSB は必要ありません。
ただし、議論の対象となる領域の 1 つは、Employee や PurchaseOrder などのドメイン オブジェクトに関するものです。これらはアプリケーション層にまたがっており、アノテーションで起こっていると思われることの 1 つは、ドメイン オブジェクトが特定の層に関連付けられたアノテーションを取得することです。したがって、ここで ORM アノテーションを使用しても、同じドメイン オブジェクトをフォーム バッキング Bean として使用して、ドメイン/フォーム オブジェクト クラスの並列処理を回避できます。一部の人々は、関心のアーキテクチャ上の分離に違反していると反対しています。