Multilayered enterprise application use of JAXB objects

Question

I am asked to refactor and maintain an enterprise application. Normally I'm used to using the MVC design pattern. This time however, I'd like to separate everything into layers (multilayered architecture). Something along the lines of (Microsoft Application Architecture Guide, 2nd Edition - October 2009):

My data sources are in general XML files. These files are read and written with the use of JAXB, and this resides in the data-layer. Whenever I load a specific XML a "provider" will use JAXB to construct a tree of objects representing the XML structure. These objects/information needs to be used inside the business, service and presentation layer. Per layer the information needs to be treat differently, i.e. business layer will enforce business rules on the objects/information whereas the presentation layer needs additional UI information to have everything shown to the user.

I'm looking for your tips / experiences when it comes down to using data sources throughout an multilayered application. Should I:

1. Create some sort of mapping, such that a new object tree is constructed in every layer?
2. Work via the lines of aggregation, such that my data sources can be decorated with extra functionality / information inside an object that lives in another layer?
3. Make the JAXB-objects "fat", with an interface which supports all my needs that come from all other layers?

I'd love to hear your thoughts!

Answer 1

I would recommend the following:

• Implement the data layer using an established ORM framework. My favorite is myBatis, but JPA and Hibernate are definite contenders.
• Wrap the data layer with a Java API that supports only business operations (not CRUD operations)- e.g. Read customer details, enrol new customer, cancel customer, place order etc. That way you are free to decide in the data layer if you need to record history, do transaction logging etc. It also has the advantage that heavy operations (e.g. Batch jobs) can use the API direct, while enterprise-wide operations use SOAP or similar. The important point is that all clients end up using the same API.
• If your data layer is well designed, the business layer should be almost a pass-through. If not, you are probably on the road to ruin, as your database does not reflect how you do business.
• MVC is great for the GUI layer, but in my view has limited application elsewhere. If you get it right, the model layer will consist simply of an aggregation of some of your DAO POJOs. View will be JSPs, JSF or some other established technology. I like to use Spring Web MVC with JSPs, but there are lots of alternatives.
• External system mapping should be flexible, allowing you to map from someone elses view of reality to your own internal enterprise data model. Standardised protocols like SOAP win here, but there seems to be a move to REST interfaces, which don't yet have the same level of definition.

In any case, there is more than one "correct" answer. there is a long-standing joke that if you ask three software architects for an opinion, you will get at least 4 answers...