Springによるプレゼンテーション層とビジネス層の分離

Question

完了したばかりのプロジェクトで、分散トランザクションを機能させていました。

JBossのArjuna Transaction ManagerとSpringの宣言的なトランザクション境界を使用してこれを実装しました。

リクエストシーケンスは次のようになりました：

browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO

これは、セキュアなサーブレットを提供するWARとSLSBを提供するEARがあったことを意味します。

SLSBには、Springアプリケーションコンテキストをブートストラップするための静的初期化ブロックがありました。

テクノロジーの組み合わせは好きではありませんが、プレゼンテーション層とビジネス層の分離は好きです。これらは異なる物理的な場所に存在する可能性があります。

Springを使用する際に、他の人がティアを分離することを提案しているものを知りたいですか？

Answer 1

ファサードであるSLSBだけのためにEJB3アプリサーバーを要求することは、私にとって努力する価値があるとは思えません。それを削除して、サーブレットをSpringで直接動作させることができない理由はありません。 ContextLoaderListenerをWARに追加してApplicationContextをロードし、次にWebApplicationContextUtilsを取得して取得できます。代わりに、サーブレット自体が許可する以上のことを行う必要がある場合は、SpringMVC、Struts、またはその他のWebテクノロジーを使用できます。

Answer 2

非常に典型的なアプローチは、Web層、サービス層、およびDAO層を定義し、トランザクションセマンティクスをサービス層にアタッチすることです。サービス層は、たとえば@Transactionalアノテーションを含むPOJOの束である場合があります。 Web層は、Spring Web MVCコントローラーである場合があります。このアプローチでは、Web層は基本的にサービス層をHTTPに適合させています。ここでは分離が良好で、SLSBは不要です。

ただし、議論の1つの領域は、EmployeeやPurchaseOrderなどのドメインオブジェクトに関するものです。これらはアプリケーション層にまたがっており、アノテーションで発生していると思われることの1つは、ドメインオブジェクトが特定の層に関連付けられたアノテーションを取得することです。したがって、ここでORMアノテーションを使用できますが、同じドメインオブジェクトをフォームバッキングBeanとして使用して、並列ドメイン/フォームオブジェクトクラスを回避します。一部の人々は、関心事のアーキテクチャ上の分離に違反していると反対しています。