If you want to have a good understanding of what SDO is about, you have to compare it to equivalent tools.
SDO has several aspects to it:
- "data object" implies some sort of collaboration with a DB.
I'm less familiar with this.
- heavyweight DTO replacement with object graph semantics.
- Smart Value Object - is very easy to grasp. very useful as well.
- The following TSS SDO thread from last year mentions SVO.
- Also note this TSS thread about SVO.
- There is, however, a misconception in the SVO FAQ regarding SDO. the under-documented Eclipse implementation of SDO (SDO javadoc is ok though) available at the Eclipse EMF project allows generation of SDO objects according to Ecore models with all specified getters and setters. In this case the SDO api also doubles as an spi and the user is mostly exposed to code that makes internal use of it. Not exactly POJO, quite brittle, but as long as you stick with generation you're fine.
- Detached object graphs are available under JDO 2.0 and Hibernate. Robin Roos has an article comparing JDO 2.0 to SDO in terms of dealing with detached object graphs.
- The aged XDoclet manages to make an appearance here as well. The XDoclet value object module offers some abstraction over DTO's.</a>
- The big mama of detached object graphs is the now-halted CarrierWave project. That project laid much of the groundwork for going beyond DTO's, and my guess is that it inspired SDO.
- Chris Wensel, the man behind the project, still blogs about CarrierWave every once in a while. Interesting blog, too.
I researched this about half a year ago and decided to go with Hiberate detached objects out of convenience. Given a more encouraging eco-system around SDO, I'd take it over using a naked data model every day. One of the selling points of the EMF-SDO implementation is model transformation (once we have Q/V/T) that allows different data models for different tiers.