There is another approach completely which is to use a product/project that is focussed on Data <-> Service mapping. [Disclosure - my company has an opensource offering in this space. There are also other offerings too!].
Basically you declaratively define the mapping from the SQL or NoSQL database into the XML or on-the-wire representation. There are a couple of benefits here:
1) The mapping layers of JPA and JAXB/JAXWS add a lot of "stuff" because they were designed to be used independently and you are mapping into/out-of Java. The declaration of data <-> XML is more direct and therefore cleaner and more declarative.
2) The performance of the tool can be optimized independent of the code. For example, we stream directly from the cursor onto the wire which makes a huge performance boost compared to building objects.
3) The productivity boost: we've have people tell us they've reduced the overall time taken to build/test/deploy a mapping from 2 weeks to less than a day.
Of course there are also many other factors that might influence (skills, deployment, etc) so as always YMMV.
On 11 January[masked]:07, Craig Silk <[address removed]>
There's a good amount of talk about DTO's being pointless and / or DTO's being essential and a part of a well designed, loosely coupled architecture. I think both points are valid but that does leave me wondering which direction to take.
I'm taking data from a database and ultimately passing it through a web service for consumption elsewhere. My persistence layer / domain models are JPA entities annotated with JAXB annotations so the data can be marshaled into XML before being passed to the web service (this is managed by an EJB application that sits between the web services and the domain models).
I'm constantly bugged by the thought that I should be using data transfers objects (POJO's with getters and setters) to hold the data from the entities and use JAXB annotations (in the DTO's) to create the XML payload.
So my question is: use DTO's or not?
- Separation of concerns, are entities really the right place to stick JAXB annotations anyway?
- Cheerry picking data, I can create smaller DTO's that hold a subset of what an entity returns thus making it easier to marshal XML payloads with less data.
- The cost associated with replicating data.
- Breaking the DRY principle.
- Have to introduce optional annotations (and logic) that tell JAXB what to NOT marshal... does this break the KISS principle?
I would usually turn to Martin Fowler in my times of Architectural need but I've got limited web access today.
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Craig Silk ([address removed]) from LJC - London Java Community.
To learn more about Craig Silk, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages
Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, VP, Apache Synapse
Lean Enterprise Middleware
Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.