AngularJS 응용 프로그램을 빌드하기위한 적절한 API 아키텍처

Question

최근에 AngularJS가 제공하는 양방향 바인딩을보다 잘 수용하기 위해 API를 구조화하는 방법에 관해 많은 중간 개발자들과 이야기를 나누었습니다. 우리는 API가 정의에 따라 매우 명확해야할지 여부를 결정하려고 시도해 왔지만, Angular에서는 더 잘 작동하지만 중간 계층에는 조금 더 많은 작업이 필요하거나 더 암시 적이거나 Angular에서 "massage" 좋은 각도 모델로 데이터.

예제를 시작하십시오. 우리가 일종의 데이터 백업 서비스에 대해 이야기하고 있다고 가정 해보십시오. 이 서비스를 통해 데이터를 백업하고 X 년 또는 무한정 데이터를 보존 할 수 있습니다. UI에는이 논리를 제어하는 ​​2 개의 요소가 있습니다. <select>을 사용하면 X 년 동안 "Never"또는 "After"데이터를 삭제할지 여부를 선택할 수 있습니다. "Never"를 선택하면 년 입력을 숨기지 만, "After"를 선택하면 연도 입력을 표시하고 1-99 사이의 숫자를 입력 할 수 있습니다.

여기서는 $scope 모델에서 각각 다른 속성을 제어하는 ​​2 개의 요소 컨트롤을 소개했습니다.

그러나 API에서 내 중간 계층 사람은 "YearsRetention"이라는 단일 속성을 사용하여이 모든 것을 제어하려고합니다. YearsRetention == 0이면 "내재적으로"는 무제한 보존을 원하지만,> 0으로 설정하면 보존이 해당 값으로 설정됩니다.

기본적으로 그는이 단일 값을 사용하여 보존 설정을 제어하려고하므로 UI에서 동일한 효과를 얻기 위해 $ 범위의 값을 설정하기 위해 일종의 변환 함수를 작성해야합니다. 이 변환은 들어오는 데이터와 나가는 데이터 모두에서 발생해야합니다.

결국 API를 암시 적으로 정의해야하는지 (API가 단일 값을 보내고 Angular가 데이터를 사용 가능한 뷰 모델로 변환해야 함) 또는 명시 적으로 API가 (API가 직접 바인딩하는 데 필요한 모든 값을 전송하는지) 알고 싶습니다. UI로 변환하여 JSON을 변환 할 필요성을 줄여야합니까?)

Answer 1

당신이 묘사하는 디자인에는 2 가지 나쁜 아이디어가 있다고 생각합니다.

1. UI의 편리 성을 기반으로 데이터 구조를 정의합니다. API를 명확하고 다용도로 (다른 UI를 가진 다른 클라이언트를 잠재적으로 지원)하고 오래 사용할 수 없기 때문에 (API 리팩토링은 운영비가 비쌉니다.) 나쁜 생각입니다. 대신 가장 정확하고 가장 정확하고 가장 일반화 된 형식으로 데이터를 정확하고 간결하게 표현하고 서식, 잘라 내기, 지역화, 측정 단위, 페이지 레이아웃 등과 같은 프레젠테이션 문제를 UI에 남겨 둡니다.
2. "마법 값"으로 자연스럽게 모델링하지 않는 개념을 표현하기 위해 단일 데이터 필드를 오버로드합니다. 숫자 의미에 여분의 의미 론적 의미를 할당하는 것은 이것의 한 예이며 일반적으로 오류가 발생하기 쉽고 혼란스럽고 새기 쉬운 추상으로 간주됩니다. 모든 클라이언트는 영의 의미가 영원하다는 마법의 의미를 암호화해야합니다. 물론 제로의 진정한 의미가 "전혀 아님"이라는 눈부신인지 부조화가 있습니다. 나는 2 필드로 모델을 만들었는데 정확히이라는 열거 형을 사용하여 "PERMANENT"와 "YEARS"그리고 연도를 나타내는 정수를 저장하는 별개의 필드 retentionValue을 모델링했습니다. 당신이 백엔드 개발자와 논쟁을 잃는다면 적어도 마법 값은 -1 대신 영원히 의미해야한다고 주장 할 것입니다. (나는 또한 null이 "전혀 아닙니다"와 "영원히"같다고 생각합니다. 내가 -1이 나쁜 마법 옵션의 가장 나쁜 점이라고 생각하는 이유입니다.특정 경우 내가 retentionPeriod를 제어하는 ​​것입니다 당신의 UI의 드롭 다운 중 하나를 주장하는 것, 다른 하나는 retentionValue을 제어하는 ​​것 적어도 거기에 이것에 대한 몇 가지 선례)

이있다. 그러나 이것이 내 UI 구현과 직접적으로 짝을 이루기 때문에 발생하는 것은 아닙니다. (이는 더 행복한 우연의 일치입니다.) 데이터의 명확한 표현이기 때문입니다.

내 경험에 따르면이 특정 인스턴스는 매우 약했다. 배열과 객체의 모호한 선택, 막연하거나 혼란스러운 이름 지정, 거대한 데이터 구조, 과도하게 수다스러운 API 등에 대해서는 훨씬 더 강력하게 우려 할 것입니다.