Должен ли SDO (Service Data Object) быть принят в новом проекте?

Question

Я программирую на Delphi с Midas / DataSnap довольно долгое время и вполне доволен этим.Переходим к .NET Я более чем доволен ADO.NET Набором данных.Что касается приложения CRUD, то мне крайне неудобен любой вид ORM.Универсальная структура данных с автоматической обработкой различий / дельта улучшает мою работу для меня, среднестатистического разработчика приложений для баз данных.

Пытался изучать Java много лет назад, но не смог найти реализованной подобную идею.Самое близкое, что я смог найти, - это SDO (Service Data Object).Я думал, что это должно быть широко распространено, когда увидел это, но я ошибаюсь.Даже сейчас спецификация довольно старая, я все еще с трудом нахожу, чтобы многие люди обсуждали ее или широко использовали.Исходя из информации, которую я могу найти в Интернете, использование SDO крайне пассивно.

Интересно , умирает ли оно ?Есть какой - нибудь опыт в SDO , которым вы хотите поделиться ?Ручное кодирование DTO всегда лучше ?

Answer 1

ОК.Я понимаю.Ответ - "нет".

;)

Answer 2

То же самое для меня, когда я пробую SDO в первый раз.Старые спецификации, пассивная обратная связь...Определенно НЕТ.

Answer 3

Я бы не рекомендовал использовать SDO, если только это не навязано вам какой-то другой частью проекта.

WebSphere process server использует SDO.На самом деле это не такой уж плохой API, как только вы его изучите.Но спецификация и документация расплывчаты.В нем не объясняется, что произойдет, если вы запросите поле, которого не существует, или выполняет ли оно преобразования типов при получении или настройке полей, чтобы назвать две проблемы.

Я не думаю, что API определяет, как определять новые типы, так что эта часть будет зависеть от конкретной реализации.Определения типов основаны на XSD, поэтому вы будете работать с ними и всеми связанными стандартами.

Как предполагали другие, API используется не так широко.Это означает, что будет трудно найти людей, имеющих опыт работы с ним, или помочь использовать его.