Should SDO (Service Data Object) ser adotado em novo projeto?

Question

Eu tenho programado em Delphi com Midas / DataSnap por muito tempo e muito feliz com ele. Movendo-se para .NET Estou mais do que feliz com o ADO.NET DataSet. Para aplicação CRUD, eu sou altamente desconfortável com qualquer tipo de ORM. Generic data-estrutura com diff automática / manuseio delta fazer meu trabalho melhor para mim, um desenvolvedor médio de aplicação de banco de dados.

Tentou estudar Java anos atrás, e não poderia encontrar ideia semelhante implementado. O mais próximo que eu poderia encontrar é SDO (Service Data Object). Eu pensei que deveria ser amplamente adotado quando eu vi isso, mas eu estou errado. Mesmo a especificação é bastante velho agora, eu ainda dificilmente encontrará muitas pessoas discutem sobre ele ou usá-lo extensivamente. Assumindo a partir de informações que pode encontrar na internet, uso de SDO é altamente passiva.

Quer saber se ele está morrendo? Qualquer experiência em SDO você quer compartilhar? codificação DTO manual é sempre melhor?

Answer 1

Ok. Entendo. A resposta é "não"

;)

Answer 2

Mesmo para me ao tentar SDO primeira vez. especificações antigas, feedback passiva ... Definitivamente NÃO.

Answer 3

Eu não recomendo o uso de SDO a menos que seja imposta a você por alguma outra parte do projeto.

processo servidor WebSphere usa SDO. Não é realmente uma má API uma vez que você aprender. Mas a especificação e documentação são vagos. Ele não especifica o que acontece se você perguntar para um campo que não existe, ou se ele faz conversões de tipo ao obter ou definir campos, para citar duas queixas.

Eu não acho que as define API como definir novos tipos, de modo que parte será de aplicação específica. definições de tipo são baseados em XSD, assim você estará trabalhando com esses e todos os padrões associados.

Como outros já implícita, a API não é amplamente utilizado. Isso significa que ele vai ser difícil encontrar pessoas experientes com ele, ou ajuda a usá-lo.