Следует ли использовать SDO (объект данных службы) в новом проекте?
Я давно программирую на Delphi с Midas/DataSnap и доволен этим. Переезд на.NET Я более чем доволен ADO.NET DataSet. Для CRUD-приложения мне крайне неудобно с любым видом ORM. Общая структура данных с автоматической обработкой различий и различий позволяет мне, обычному разработчику приложений для баз данных, лучше выполнять свою работу.
Пытался изучать Java много лет назад, но не смог найти подобную идею реализованной. Самое близкое, что я мог найти, это SDO (Service Data Object). Я думал, что это должно быть широко принято, когда я увидел это, но я ошибаюсь. Даже спецификация сейчас довольно старая, я все еще вряд ли смогу найти много людей, обсуждающих ее или широко использующих. Исходя из информации, которую я могу найти в Интернете, использование SDO очень пассивно.
Хотите знать, если он умирает? Какой опыт в SDO вы хотите поделиться? Ручное кодирование DTO всегда лучше?
3 ответа
Я бы не рекомендовал использовать SDO, если он не навязан вам какой-либо другой частью проекта.
Сервер процессов WebSphere использует SDO. Это не очень плохой API, как только вы его изучите. Но спецификация и документация расплывчаты. В нем не прописано, что происходит, если вы запрашиваете несуществующее поле или выполняет ли преобразование типов при получении или задании полей, чтобы назвать две пробелы.
Я не думаю, что API определяет, как определять новые типы, так что эта часть будет зависеть от реализации. Определения типов основаны на XSD, поэтому вы будете работать с этими и всеми соответствующими стандартами.
Как и предполагали другие, API широко не используется. Это означает, что будет трудно найти людей, которые с этим сталкивались, или помочь в их использовании.
То же самое для меня при попытке SDO в первый раз. Старые спецификации, пассивная обратная связь... Определенно НЕТ.