5

Currently I am working on a project with Spring web-service, hibernate and JAXb.

1) I have generated hibernate beans using IDE 'hibernate code generation,

2) also, I have generated the jaxb beans using maven compiler.

..

Now, my question is,

1) Is this the right approach? (to have so many beans).

2) Shall I use JAXb beans for processing into the service layer? How can I keep layers decoupled?

3) Or, do I need to create another set of beans ie. map (JAXb beans) to (new beans) to (hibernate beans)?

.

Please tell your views?

Thanks, adi

HefferWolf
  • 3,894
  • 1
  • 23
  • 29
adi
  • 1,711
  • 3
  • 29
  • 50

2 Answers2

5

You know, you cannot have everything fully decoupled. There will be always a layer that will know the other two layers.

Usually when I design 3 layers architecture, like:

  1. Service Layer - the one that probably uses JAXB, exposes web services or other APIs
  2. Business Layer - any real logic
  3. Persistence Layer - hibernate

I allow the Business layer to know about the Service Layer (JAXB) and about the Persistence Layer (hibernate beans). But I don't allow the Service Layer and the Persistence Layer to know about each other.

Tarlog
  • 10,024
  • 2
  • 43
  • 67
  • Thanks, much appreciated. So,having JAXb beans and Hibernate beans is fine? In this case I will have to do jaxb->hibernate beans mapping in the business layer. Is it so? – adi Oct 26 '11 at 08:01
  • Yes. From my experience, usually the service layer beans and the persistence layer beans are not identical. You may think about them as identical, when you start the design, but later the API layer has one kind of implications, while the persistence layer may have the other kind. – Tarlog Oct 26 '11 at 08:04
  • OK. I am actually just scary about doing mapping using e.g. JAXBElement classes in the business layer. This way my business layer is tied to the webservices. If I need to write another client (which needs to access the business layer), it will not be good. – adi Oct 26 '11 at 08:41
  • 4
    I didn't say that the business layer will use the JAXB classes internally. But it will receive them from the service layer. Your problem doesn't have a fully correct or fully incorrect solution. Try to find the balance. – Tarlog Oct 26 '11 at 12:26
  • +1 for "Your problem doesn't have a fully correct or fully incorrect solution. Try to find the balance." – bdoughan Oct 26 '11 at 14:07
3

Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB 2 (JSR-222) expert group. EclipseLink also provides an excellent JPA implementation (open sourced from TopLink).

There are costs to maintaining multiple models. Each model you add introduces a bean-to-bean conversion that must be written, tested, and maintained.

Another approach is to use the same beans for both the JPA and JAXB bindings. For this use case it will be easier to start with domain model and add JAXB & JPA metadata to apply mappings to XML and the database. Below is example of where a single model is leveraged to create a RESTful web service:

Since EclipseLink provides both JAXB and JPA implementations we provide a number of extensions to make this easier:


UPDATE

In response to:

Agree to what you are saying. However, using same beans will couple the code very tightly and will be highly dependent. Change in one layer will need changes elsewhere as well. What you say?

It all depends how you look at things. My preference for building data access services is to design and build a solid domain model. Then use JPA and JAXB to solve the impedance mismatches between object-relational and object-XML.

One Model Approach

Using one model for both JPA and JAXB means that when you make a change to the model you need to decide at that time how it will be handled for both JPA and JAXB (this can be good or bad). If you don't want every new addition to the model to affect the JAXB mapping you can leverage JAXB concepts like @XmlAccessorType(XmlAccessType.NONE).

Two (or More) Models Approach

When you want to add a field that is mapped to both relational and XML you need to add it to two models and add the necessary conversion logic. In this case there is a cost to keeping the models de-coupled.

Pyves
  • 6,333
  • 7
  • 41
  • 59
bdoughan
  • 147,609
  • 23
  • 300
  • 400
  • Agree to what you are saying. However, using same beans will couple the code very tightly and will be highly dependent. Change in one layer will need changes elsewhere as well. What you say? – adi Oct 26 '11 at 11:31
  • how would you deal with the case when you have either multiple datalayer beans ? e.g. : JPA, and opencsv or other text based beans ? Does coupling all of those still makes sens ? – Frederic Bazin Dec 16 '12 at 18:07