Devrait-on adopter SDO (Service Data Object) dans un nouveau projet?

Question

J'ai programmé en Delphi avec Midas/DataSnap depuis longtemps et j'en suis très content. Passer à .NET Je suis plus qu'heureux avec le DataSet ADO.NET. Pour l'application CRUD, je suis très mal à l'aise avec tout type d'ORM. La structure de données générique avec traitement différentiel/delta automatique permet d'améliorer mon travail pour moi, un développeur moyen d'applications de base de données. Essayé d'étudier Java il y a des années, et ne pouvait pas trouver une idée similaire implémentée. Le plus proche que j'ai pu trouver est SDO (Service Data Object). Je pensais qu'il 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 à peine beaucoup de gens discutent dessus ou l'utilisent beaucoup. En supposant des informations que je peux trouver sur Internet, l'utilisation SDO est très passive.

Vous vous demandez si elle est en train de mourir? Une expérience dans SDO que vous voulez partager? Le codage DTO manuel est toujours meilleur?

Answer 1

Ok. Je vois. La réponse est "non"

;)

Answer 2

Même pour moi en essayant SDO première fois. Anciennes spécifications, rétroaction passive ... Certainement NON.

Answer 3

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

Le serveur de processus WebSphere utilise SDO. Ce n'est pas vraiment une mauvaise API une fois que vous l'avez appris. Mais les spécifications et la documentation sont vagues. Il n'indique pas ce qui se passe si vous demandez un champ qui n'existe pas, ou s'il tape des conversions lors de l'obtention ou de la définition de champs, pour nommer deux saisies.

Je ne pense pas que l'API définisse comment définir de nouveaux types, donc cette partie sera spécifique à l'implémentation. Les définitions de type sont basées sur XSD, vous allez donc travailler 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.