新项目是否应该采用SDO（服务数据对象）？
我已经使用 Midas/DataSnap 在 Delphi 中进行编程很长时间了，并且对此非常满意。 转向 .NET 我对 ADO.NET 数据集非常满意。 对于 CRUD 应用程序，我对任何类型的 ORM 都感到非常不舒服。 对于我这个普通的数据库应用程序开发人员来说，具有自动差异/增量处理功能的通用数据结构可以更好地完成工作。
几年前尝试研究Java，但找不到类似的想法实现。 我能找到的最接近的是SDO（服务数据对象）。 当我看到它时，我认为它应该被广泛采用，但我错了。 即使规范现在已经相当老了，我仍然很难找到很多人讨论它或广泛使用它。 从我在互联网上找到的信息来看，SDO 的使用是高度被动的。
想知道它会死吗？ 您在 SDO 方面有什么经验想分享吗？ 手动 DTO 编码总是更好？
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 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好的。 我懂了。 答案是不”
;）
Ok. I see. The answer is "no"
;)
我第一次尝试 SDO 时也是如此。 旧规格、被动反馈……绝对不行。
Same for me when trying SDO first time. Old specs, passive feedback... Definitely NO.
我不建议使用 SDO，除非项目的其他部分强加给您。
WebSphere 流程服务器使用 SDO。 一旦你学会了它，它并不是一个糟糕的 API。 但规范和文档含糊不清。 它没有说明如果您请求一个不存在的字段会发生什么，或者在获取或设置字段时是否进行类型转换，仅举两个抱怨。
我不认为 API 定义了如何定义新类型，因此该部分将是特定于实现的。 类型定义基于 XSD，因此您将使用这些标准和所有相关标准。
正如其他人所暗示的那样，该 API 并未得到广泛使用。 这意味着很难找到有经验的人或帮助使用它。
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.