관리 대상 개체에 대한 변경 사항을 조작하고 추적하기 위한 개체 공간입니다.
Context는 하나 이상의 영구 저장소에 대해서 내부적으로 일관된 View를 나타내는 관련 모델 객체그룹으로 구성된다. 관리되는 객체에 대한 변경사항은 Core Data가 해당 Context를 하나이상의 영구 저장소에 저장할때까지 연결된 Context의 메모리에 남아 있다. 단일 관리 객체 인스턴스는 하나의 Context에만 존재하지만 객체의 여러 복사본이 다른 Context에 존재할 수 있다. 따라서 객체는 특정 Context에게 고유하다.
Context는 Lift Cycle 관리(오류 포함)에서 유효성 검사, 역 관계 처리 및 실행 취소/다시 실행에 이르기까지 책임이 있는 관리 객체의 수명주기에서 중심 역할을 하는 강력한 객체이다. Context를 통해 영구 저장소에서 객체를 검색하거나 “Fetch”하고 해당 객체를 변경한 다음 변경 사항을 취소하거나 다시 Context를 통해 영구 저장소에 커밋할 수 있다. Context는 해당 객체의 변경 사항을 감시하는 책임이 있으며 실행 취소 및 다시 실행을 보다 세밀하게 제어할 수 있도록 실행 취소 관리자를 유지한다.
새 객체를 삽입하고 가져온 객체를 삭제할 수 있으며 이러한 수정 사항을 영구 저장소에 커밋할 수 있다.
외부 저장소에서 가져온 모든 객체는 각 객체를 외부 저장소에 고유하게 식별하는 데 사용되는 전역 식별자(NSManagedObjectID)와 함께 Context에 등록된다.
관리 객체 Context에는 관리 객체를 나타내는 데이터를 검색하고 관리 객체에 대한 변경 내용을 커밋하는 상위 저장소가 있다.
OS X v10.7 및 iOS v5.0 이전에는 상위 스토어가 항상 영구 스토어 코디네이터였습니다. macOS 10.7 이상 및 iOS v5.0 이상에서 상위 저장소는 다른 관리 객체 컨텍스트일 수 있습니다. 궁극적으로 컨텍스트 조상의 루트는 영구 저장소 조정자여야 합니다. 코디네이터는 관리 객체 모델을 제공하고 데이터를 포함하는 다양한 영구 저장소에 요청을 발송합니다.
Context의 상위 저장소가 다른 관리 객체 Context인 경우 가져오기 및 저장 작업은 Coodinator 대신 상위 Context에 의해 중재된다. 이 패턴에는 다음과 같은 다양한 사용 시나리오가 있다.
두 번째 Thread 또는 Queue에서 Background 작업을 수행한다. Inspector window나 View에서와 같이 삭제 가능한 편집을 관리한다.
첫 번째 시나리오에서 알 수 있듯이 상위 Context는 다른 Thread에 있는 하위의 요청을 처리할 수 있다. 따라서 Thread 제한 타입으로 생성된 상위 Context를 사용할 수 없다. (Concurrency 참조)
Context에서 변경 사항을 저장하면 변경 사항이 “한 단계 위로" 커밋된다. 하위 Context를 저장하면 변경 사항이 상위 Context로 푸시 된다. Root Context가 저장될때까지 변경 사항이 영구 저장소에 저장되지 않는다. (Root 관리 객체 Context는 상위 Context가 nil인 Context이다.) 또한 상위는 저장하기 전에 하위에서 변경사항을 가져오지 않는다. 궁극적으로 변경사항을 커밋하려면 자식 Context를 저장해야 한다.