CODEWITHSUNDEEP
javaweb-servicesjpajaxb
Manuel Faux
Manuel Faux

Reputation: 2457

Persisting BOs used for XML Serialization

Is it a good idea to use one and the same set of business objects for serialization via XML (via JAXB for use with e.g. JAX-WS) and for persisting with JPA? Are there disadvantages of combining these two "paradigms" into one class?

One of my classes looks e.g. like this:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "testSuiteInfo", propOrder = {
    "name",
    "tests"
})
@Entity
public class TestSuiteInfo {

    @Id
    @GeneratedValue
    @XmlTransient
    protected Long id;
    protected String name;
    @XmlElement(nillable = true)
    @OneToMany
    protected List<TestInfo> tests;

    // Getters and setters go here...
}

An object of that class is being received by JAX-WS and would then be persisted by JPA.

Upvotes: 1

Views: 73

Answers (1)

lexicore
lexicore

Reputation: 43671

I'm the author of Hyperjaxb3, XJC plugin which adds JPA annotations to schema-derived classes. So you can just take a schema and then be able to do the full XML-objects-DB rountrip. MOXy can map JPA entities to XML as well.

Now back tou your question. If you use the same classes for the database, XML representation and the business logic then you essentially have the same model for all three things. If this works for you - fine! In many cases this indeed works since

  • BOs often tend to be rather simple
  • there are no specific requirements for the database (i.e. performance)
  • you can control the XML Schema representing your BOs

In these cases it is quite fine to have XML-objects and objects-DB with the same classes.

Now consider a more complicated case:

  • you can't control your XML Schema as its is some kind of specification for an exchange interface
  • you have performance requirements and have to model the database schema accordingly
  • you want a polished BO code for your business logic with added-value methods and not just schema-derived stuff

All of these things put specific constraints/requirements on your XML, JPA and BO parts. Can you fulfill all of these requirements with just one model (no matter if it is JAXB or JPA)? Unlikely. You'll probably be much better off generating the JAXB classes from you specification schema and - separately - carefully designing you JPA entities. Right, you'll need a mapper in this case, but this is a lesser evil.

Consider also the following questions:

  • What happens if your spec schema changes? If another version will be published and you need to support it?
  • What if you'll have to implement some new feature in JPA or in the database? Like, denormalize something to achieve better performance?

From the other hand, if you

  • go XML Schema-first and don't care much about the database (just need to persist things somehow) or
  • go JPA-first and don't care much about XML (just need to serialize stuff in XML) and
  • don't waste effort writing mappers

then having JPA and JAXB in the same class is quite OK, why not. (The first approach would be Hyperjaxb3, the second - MOXy).

Upvotes: 1

Related Questions