Le SDO (Service Data Object) doit-il être adopté dans un nouveau projet?

Question

Je suis programmé sous Delphi avec Midas / DataSnap depuis assez longtemps et très content. Passage à .NET Je suis plus que satisfait du jeu de données ADO.NET. Pour l'application CRUD, je suis très mal à l'aise avec tout type d'ORM. Une structure de données générique avec traitement automatique des différences / deltas améliore mon travail, en tant que développeur d'applications de bases de données.

J'ai essayé d'étudier Java il y a plusieurs années et je n'ai pas trouvé d'idée similaire mise en œuvre. Le plus proche que je puisse trouver est SDO (Service Data Object). Je pensais que cela devrait être largement adopté quand je l'ai vu, mais je me trompe. Même la spécification est plutôt ancienne maintenant, je trouve encore difficilement que beaucoup de personnes en discutent ou l'utilisent à fond. D'après les informations que je peux trouver sur Internet, l'utilisation de SDO est hautement passive.

Vous vous demandez si c'est en train de mourir? Une expérience en SDO que vous souhaitez partager? Le codage manuel DTO est toujours mieux?

Answer 1

Ok. Je vois. La réponse est & "Non &";

;)

Answer 2

Idem pour moi lors de la première utilisation de SDO. Anciennes spécifications, rétroaction passive ... Absolument NON.

Answer 3

Je ne recommanderais pas d'utiliser SDO à moins que cela ne vous soit imposé par une autre partie du projet.

WebSphere Process Server utilise SDO. Ce n'est pas vraiment une mauvaise API une fois que vous l'apprenez. Mais les spécifications et la documentation sont vagues. Cela ne précise pas ce qui se passe si vous demandez un champ qui n'existe pas, ou s'il saisit des conversions lors de l'obtention ou de la définition de champs, pour nommer deux problèmes.

Je ne pense pas que l'API définisse comment définir de nouveaux types, de sorte que cette partie sera spécifique à l'implémentation. Les définitions de type étant basées sur XSD, vous travaillerez donc avec celles-ci et toutes les normes associées.

Comme d'autres l'ont laissé entendre, l'API n'est pas largement utilisée. Cela signifie qu'il sera difficile de trouver des personnes expérimentées ou d'aider à l'utiliser.