새 프로젝트에서 SDO (Service Data Object)를 채택해야합니까?

Question

저는 꽤 오랫동안 Midas/DataSnap을 사용하여 Delphi에서 프로그래밍을 해왔고 꽤 만족합니다. .NET으로 이동하기 ADO.NET DataSet에 만족합니다. CRUD 응용 프로그램의 경우 모든 ORM에 대해 매우 불편합니다. 자동 diff/delta 처리 기능을 갖춘 일반 데이터 구조는 평균적인 데이터베이스 응용 프로그램 개발자 인 저에게 도움이됩니다.

자바 년 전 연구를 시도했지만 유사한 아이디어가 구현되지 않았습니다. 가장 가까운 것은 SDO (Service Data Object)입니다. 내가 그것을 보았을 때 폭넓게 받아 들여야한다고 생각했지만 틀렸어. 스펙이 꽤 오래되었지만, 많은 사람들이 그것에 대해 토론하거나 광범위하게 사용한다는 사실을 거의 발견하지 못합니다. 인터넷에서 찾을 수있는 정보로 가정하면 SDO 사용은 매우 수동적입니다.

죽어 가고 있는지 궁금하십니까? SDO에서 공유하고 싶은 경험이 있습니까? 수동 DTO 코딩이 항상 더 좋습니다.

Answer 1

확인. 내가 참조. 대답은 "아니오"

없다) SDO를 처음 시도 할 때 나를 위해

Answer 2

동일합니다. 오래된 스펙, 수동 피드백 ... 확실히 아니오.

Answer 3

SDO는 프로젝트의 다른 부분에서 부과하지 않는 한 사용하지 않는 것이 좋습니다.

WebSphere Process Server는 SDO를 사용합니다. 일단 배우면 나쁜 API는 아닙니다. 그러나 스펙과 문서는 모호합니다. 존재하지 않는 필드를 요구하거나 필드를 가져 오거나 설정하는 동안 유형 변환을 수행하는지 여부를 묻는 두 가지 불만을 말하면 어떤 일이 일어나는 지 철자하지 않습니다.

API가 새 유형을 정의하는 방법을 정의하지 않았으므로 해당 부분이 구현에 따라 달라질 것이라고 생각합니다. 유형 정의는 XSD를 기반으로하므로 관련된 모든 표준을 사용하여 작업하게됩니다.

다른 것들과 마찬가지로, API는 널리 사용되지 않습니다. 즉, 경험이 많은 사람들을 찾거나 사용하는 것을 돕는 것이 어려울 것입니다.