그 이유는 다음과 같습니다.

이러한 규칙은 성능 향상을 목표로하는 것으로 보입니다.

이 몇 가지 규칙에 대한 몇 가지 발언이 있습니다.:

• 요구 사항이 없으면(여러 컨트롤러에서 사용)구성 요소 컨트롤러 수준에서 컨텍스트를 만들지 말고 필요한 경우 로컬 컨텍스트를 만듭니다(예:뷰

구성 요소 컨트롤러는 컨텍스트의 중앙 허브입니다. 언제든지 여러 뷰에서 공유되는 컨텍스트 노드가 있는 경우 구성 요소 컨트롤러에 노드를 만들어 다른 뷰에 매핑해야 합니다.

특정 뷰와 관련된 노드는 뷰 컨텍스트에서 직접 생성 될 수 있지만 가독성과 균일 성을 위해 모든 컨텍스트 노드를 중앙 집중화하고 구성 요소 컨트롤러에서 메소드를 제공하기로 선택합니다.

• 중첩(마스터 세부 사항)이 필요한 경우 싱글 톤 노드를 사용하십시오

싱글 톤 노드는 각(비활성)부모 개체에 대해 여러 인스턴스를 갖는 대신 노드의 인스턴스를 하나만 메모리에 유지하므로 성능에 좋습니다. 그러나 여러 개의 활성 부모 요소(행 반복기,중첩 테이블,트리,다중 선택 테이블)가 필요한 상황에 처하면 무엇을하고 있는지 더 잘 알 수 있습니다…)싱글 톤 노드는 응용 프로그램을 덤프합니다.

싱글톤 노드의 원리를 잘 모르거나 성능이 문제가 되지 않으면 싱글톤 노드를 사용하지 마십시오.

• 동적 특성을 사용하지 마십시오.)

정적으로 정의된 컨텍스트 속성을 사용할 수 있는 경우 정적 속성을 사용합니다. 그러나 컨텍스트를 동적으로 만들어야 하는 상황이 있습니다. 이러한 경우 동적 특성을 추가하는 것 외에는 선택할 수 없습니다. 그러나 동적 컨텍스트 프로그래밍(및 동적 뷰 프로그래밍)을 가능한 한 피해야한다는 데 동의합니다.

• 내부적으로 바인딩 작업은 이동 대응을 사용하고 그림자 변수에 원래 테이블을 유지합니다. 이동 대응 소문에 성능을 위해 나쁜 있지만. (나는 나 자신의 테스트를 수행하고 어떤 중요한 차이를 찾을 수 없기 때문에 소문에 의하면 말한다)
  • 데이터를 실제로 업데이트해야하는 경우에만 컨텍스트를 업데이트

  업데이트로 무엇을 의미합니까?

  • 긴 컨텍스트 매핑 체인을 만들지 마십시오.

  ?

  • 컨텍스트 변경 로그 함수를 사용하여 사용자 입력을 검색합니다. 이는 응용 프로그램 사용자가 많은 양의 혼합 데이터를 표시하는 동안 뷰에서 소량의 데이터만 수정하는 동안 특정 성능상의 이점을 제공합니다.

  참. 동적 방식으로 사용할 때 컨텍스트 변경 로그는 매우 강력 할 수 있습니다.

  그러나 그것은 또한 매우 발전했습니다. 컨텍스트의 모든 변경 사항을 통과하고 지원 클래스(구조의 필드 또는 내부 테이블의 행의 필드)의 적절한 변수에 데이터를 할당하고 핸들러 메소드(존재하는 경우)를 동적으로 호출 할 수있는 스 니펫이 있습니다. 이 스 니펫을 많은 고도로 숙련 된 개발자와 공유했습니다. 최신,만 2 실제로 무슨 짓을했는지 이해하고,자신의 구성 요소에 적용 할 수 있었다.

  당신이 언급 한 규칙은 충분히 흥미 롭지 만 스티브가 언급 한 것처럼 목적과 기본 아이디어에 대해 자세히 설명 할 수 있습니다.

  건배!