Should SDO (Service Data Object) be adopted in new project?

Question

I've been programming in Delphi with Midas/DataSnap for quite long time and quite happy with it. Moving to .NET I'm more than happy with the ADO.NET DataSet. For CRUD application, I'm highly uncomfortable with any kind of ORM. Generic data-structure with automatic diff/delta handling get my job done better for me, an average database application developer.

Tried to study Java years ago, and could not find similar idea implemented. The closest I could find is SDO (Service Data Object). I thought it should be widely adopted when I saw it, but I'm wrong. Even the spec is rather old now, I still hardly find many people discuss on it or use it extensively. Assuming from information I can find on the internet, SDO usage is highly passive.

Wondering if it's dying ? Any experience in SDO you want to share ? Manual DTO coding is always better ?

Answer 1

Ok. I see. The answer is "no"

;)

Answer 2

Same for me when trying SDO first time. Old specs, passive feedback... Definitely NO.

Answer 3

I wouldn't recommend using SDO unless it's imposed on you by some other part of the project.

WebSphere process server uses SDO. It's not really a bad API once you learn it. But the spec and the documentation are vague. It doesn't spell out what happens if you ask for a field that doesn't exist, or whether it does type conversions while getting or setting fields, to name two gripes.

I don't think the API defines how to define new types, so that part will be implementation-specific. Type definitions are based on XSD, so you'll be working with those and all of the associated standards.

As others have implied, the API isn't widely used. This means it'll be hard to find people experienced with it, or help using it.