디커플링 트럼프가 REST에서 DRY를 제거합니까?

기존 Java API의 기능을 대부분 공개하기 위해 REST API를 작성 중입니다. 두 API 모두 조직 내에서 사용하기위한 것입니다. 외부 용으로 디자인 할 필요는 없습니다. 두 API 모두에 영향을 주지만 REST API를 구현하고 있습니다. Java API는 로컬 응용 프로그램에 계속 사용되지만 ( "종료되지는 않음") REST API는 중요한 새로운 개발에 사용됩니다.

Java API 클래스 중 일부는 단순히 데이터 (속성, 게터, 세터가있는 Bean)입니다. 그리고 이들 중 적어도 일부는 REST API를 통해 데이터 (XML 또는 JSON에 마샬링 됨)로 (일부 형태로) 전송하는 것이 합리적입니다. 예를 들어 서버 시스템에 대한 정보를 저장하는 클래스입니다. 이러한 데이터 클래스에 대해 다음과 같은 선택에 직면 해 있습니다.

1. REST API에서 원래 Java 클래스 (또는 서브 클래스)를 직접 노출 시키거나
2. REST API를 위해 특별히 새로운 데이터 전송 클래스 (DTO 패턴)를 만드시겠습니까?

어느 쪽이든 REST 데이터 전송 클래스를 갖게됩니다. 문제는 원본에 주석을 달거나 새 원본을 만들지 여부입니다 (원본의 사본 근처에있을 수 있음). 다른 선택이있을 수 있지만 주로이 두 가지에 중점을 둘 것입니다.

# 1의 인수 :

• 건조 (반복하지 마십시오)
• 빠른 구현
• REST API를 쉽게 업그레이드

# 2의 인수 :

• REST API를 Java API와 별도로 버전 화해야하는 경우 어떻게합니까? (이는 다소 가능성이 있습니다.)
• 등록 정보 제거, 동작 추가 또는 클래스 계층 구조 변경과 같은 Java 데이터 클래스가 크게 변경되면 어떻게됩니까? (이 또한 다소 가능성이 있습니다.)

결론은 DRY (# 1)와 디커플링 (# 2) 사이의 트레이드 오프처럼 보입니다.

나는 # 1부터 시작하여 나중에 # 2로 넘어가는 데 문제가 생기면 필요하지 않은 것을 구축 할 수없는 민첩한 지침을 따라야합니다. 이것은 나쁜 생각입니까? 어쨌든 내가 끝날 것이라고 생각되면 # 2로 시작해야합니까?

내 목록에서 주요 논쟁 / 결과가 누락 되었습니까?

좋은 질문은 간단히 분리하십시오. 그것이 여기에가는 길입니다 .Java 버전에 묶이고 싶지 않습니다.

분리하지 않는 한 가지 시나리오가 있습니다. 기술에서 유형이 아닌 객체를 유선으로 전송할 수 있다면, 즉 현재 Java 객체를 YAGNI로 사용할 수 있고 다른 것으로 교체 할 수있는 경우 사용자 정의 유형은 와이어를 통해 이동하는 유형 정보로 인해 아무것도 끊지 않는 간단한 드롭 인입니다. 따라서 기본적으로 유형 정보가 와이어를 통과하지 않으면 YAGNI를 사용할 수 있습니다.

Java 버전으로 업그레이드해도 이러한 객체가 변경되지 않도록 매우 조심하고주의하십시오. 그렇지 않으면 지금 분리하고 걱정하지 않아도됩니다. 선택의 여지가 얼마나 많은지에 달려 있습니다.

그러나 유형 정보가 프로토콜에서 전선을 통과하면 기본 Java 유형 변경시 새로운 유형의 플랫 드롭 인이 불가능할 수 있으며 오히려 더 큰 노력이 될 수 있습니다. 이 경우 YAGNI로 전환한다는 것은 이제 기본 기술과 관련된 기술적 부채 및 위험이 발생한다는 의미입니다.

개인적으로 나는 지금 분리합니다.

또한 DRY는 기본 조각을 작성하지 않았으므로 코드를 복제하지 않으므로 DRY의 주요 관심사 인 버그의 고통이 전혀 없습니다. 유지할 중복 항목이 없기 때문에 다시는 가질 수없는 문제)

# 1의 주요 주장은 구현과 업그레이드의 용이성이지만 요구 사항을 충족합니까?

# 2에 대한 인수에서 Java API와 REST API가 독립적으로 변경 될 수 있음을 나타냅니다. 이것은 별도의 관심사이며 별도의 클래스를 사용하여 자신을 반복하지 않음을 의미합니다. 두 가지가 같은 모양해서, 그들이 의미하지 않는다 있습니다 동일.

REST API는 데이터 모델과 동일한 구조를 따를 필요가 없습니다.

REST를 구현할 때는 직관적 인 외부 API를 작성하고이를 내부 데이터 모델 클래스에 맵핑하십시오. 이것은 서로 독립적으로 변경하여 수십 년 동안 지속될 수있는 API로 이어질 수 있습니다 .

따라서 디커플링이 여기로가는 방법입니다.