Следует ли использовать SDO (объект данных службы) в новом проекте?

Question

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

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

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

Answer 1

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

Answer 2

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

Сервер процессов WebSphere использует SDO. Это не очень плохой API, как только вы его изучите. Но спецификация и документация расплывчаты. В нем не прописано, что происходит, если вы запрашиваете несуществующее поле или выполняет ли преобразование типов при получении или установке полей, чтобы назвать две пробелы.

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

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

Answer 3

Хорошо. Понимаю. Ответ "нет"

;)