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):

enter image description here

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!

  • recommended reading: Why is asking a question on “best practice” a bad thing?
    – gnat
    Commented Jul 7, 2014 at 13:49
  • 1
    @gnat; changed, finished my questions with asking for "best practice" when all I want is people's experiences and/or tips. Thnx anyway.
    – Velth
    Commented Jul 8, 2014 at 5:23
  • 2
    in which layer other than service layer to user and external system that compels you to create your own mapper and use JAXB objects?
    – InformedA
    Commented Jul 8, 2014 at 5:58
  • @randomA; I hope I understand your question correctly, here it goes. I want to work by means of loosely coupled layers. So whenever we change from xml to mysql, I do not want to change any other layer other than my data-layer. This in some sort compels me to create a mapping/other technique between the data-layer and business-layer. From that point onward I could keep using my business objects. But does this not break my loosely coupled principle?
    – Velth
    Commented Jul 8, 2014 at 7:19
  • It looks like your Data layer would be something like a persistence provider like JPA? If so they have built-in mapper that communicates with mysql for you. Why do you need to create your own data mapper?
    – InformedA
    Commented Jul 8, 2014 at 7:34

1 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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.