Separate presentation and business layers with Spring

Question

In my newly completed project, I was working on distributed transactions.

We implemented this using the JBoss Arjuna Transaction Manager and Spring declarative transaction boundaries.

Our query sequence looked like this:

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

This meant that we had a WAR to serve our secure servlet and EAR to serve our SLSB.

Our SLSB had a static initialization block to load our Spring application context.

I do not like the combination of technologies, but I like the separation of presentation and business levels, which can be in different physical places.

I would be interested to know what others suggest split levels when using Spring?

Answer 1

The requirement that an EJB3 application server just for SLSB, which is a façade, does not seem suitable for me. There is no reason why you cannot simply remove this, and your servlet works directly with Spring. You can add a ContextLoaderListener to the WAR to load your ApplicationContext and then WebApplicationContextUtils to get it. Alternatively, you can use SpringMVC, Struts, or other web technologies if you need to do more than Servlet allows.

Answer 2

A fairly typical approach is to define the web tier, service tier, and DAO tier and attach transactional semantics to the service tier. For example, a service level might be a POJO group with @Transactional annotations. The web tier can be Spring Web MVC controllers. In this approach, the web tier essentially adapts the service tier to HTTP. Good separation and lack of SLSB here.

One area of ​​discussion is with domain objects such as Employee or PurchaseOrder or something else. These application coverage levels and one thing that seems to happen with annotations is that domain objects receive annotations that are tied to specific levels. This way you may have ORM annotations, but then use the same domain object as the formal bean support to avoid parallel classes of object classes. Some people object to this as a violation of the architectural separation of problems.