애플리케이션이 마지막 N 릴리스의 파일 형식을 열 수 있어야하고 (아마도 저장하는 경우) 파일 형식 업데이트가 쉽고 오류가 발생하지 않도록 코드를 어떻게 체계적으로 구성해야합니까? 파일 형식이 XML이고 함수가 내보낼 개체를 가져 와서 가져올 개체를 생성한다고 가정합니다.버전이있는 파일의 가져 오기 및 내보내기 코드를 구성하는 방법은 무엇입니까?
각 함수 이름 끝에 숫자를 추가하고 복사/붙여 넣기하고 새 버전마다 번호를 증가 시킵니까? 이는 소스 코드 내에서 여러 버전의 버전 제어 기능을 유지하는 것과 같습니다. 아마도 빌드시에 마술을해야할까요?
첫째, 이전 버전을 지원하는 것이 내보내기보다 훨씬 쉽습니다. 이는 일반적으로 최신 버전이 더 많은 기능을 지원하기 때문에 달라지기 때문입니다. 따라서 이전 형식으로 저장하면 데이터가 손실 될 수 있습니다. 따라서 필자의 경험은 10 년 이상에 걸친 여러 버전의 지원을 지원하는 데있었습니다.
XML은 물론 스마트 솔루션입니다. 이 문제를 염두에두고 설계되었습니다. 핵심은 클린 데이터 모델에서 깨끗한 코드 구조가 나온다는 것입니다. 새 버전이 기능을 추가하고 추가 태그에 대한 지원으로 표시되면 기존 태그 처리를 다시 코딩 할 필요가 없습니다.
이제 은 일 수 있습니다. 기존 태그의 의미를 변경하여 다시 코딩해야합니다. 해결책 : 피할 수 있다면 이것을하지 마십시오. 특성이나 태그를 추가 할 때는 기본값을 정의한 다음 이전 데이터 파일과 새 데이터 파일을 완벽하게 처리해야합니다.
그래서 다른 파일 버전의 동일한 필드를 처리하는 데 상당히 다른 코드가있는 경우를 피할 수 있어야합니다. 이것이 일어나는 곳에서는 "특별한 상황"(소프트웨어와 함께 사는 삶)이 있다고 생각합니다. 일반적인 솔루션을 설계 할 때는 특정 유스 케이스를 염두에 두어야하며 이러한 특수한 경우는 처리되지 않을 수 있습니다.
요약하면 데이터 모델의 업그레이드 경로를 정의하면 가장 효율적으로 사용할 수 있습니다.
아마도 버전 번호가 필요합니다.
하지만 실제로 XML을 디자인하는 것이 가장 좋습니다. 그리고 XML이 직관적이고 자연스러운 방식으로 구성되어 있는지 확인하십시오. 그렇지 않으면 코드의 현재 구성이 XML 구조로 누출 될 수 있습니다. XML의 구조는 제품의 향후 버전에서 읽기가 더 어려워집니다.
열거 형 값을 저장할 때 숫자는 쓰지 않고 열거 형의 이름을 씁니다. 일부 요소가 원칙적으로 여러 번 나타날 수 있지만 현재 응용 프로그램에는없는 경우 XML로 배열로 디자인하십시오. 작성한 숫자가 문제가되는 도메인의 논리적 단위이며 현재 응용 프로그램에서 사용하는 단위가 아닌지 확인하십시오.
이렇게 작성된 XML에서는 기존 XML 버전을 지원하기가 쉽지 않습니다.
편집 : 당신이 대폭 변경 한 경우
것은, 그냥 기존 XML을 읽 레거시 데이터 객체를 구현하는 데 도움이 될 수 있습니다. 그런 다음 변환 메소드를 작성하여 이전 데이터 모델을 새 데이터 모델로 변환하십시오. 이것은 새로운 시작에 도움이됩니다. 이전 데이터 모델이 잘못 설계된 경우
+1 : 설명이 잘되어 있습니다. –