NSManagedObjectContext를 생성 한 단일 또는 큐가 소유하고 Apple이 말하는 것은 무엇을 의미합니까?
11 월에 Apple은 NSManagedObjectContext Class Reference 와 Core Data Programming Guide 문서를 모두 업데이트 하여 NSManagedObjectContext. 그러나 결혼식 조언은 모호하고 모순 될 수 있습니다. 저는 그것을 이해했는지 확인하고 싶습니다.
이전에는 NSManagedObjectContext충분하지 않고, 충분하지 않고, 충분하지 않습니다. 일련의 반복은 한 번에 하나의 작업으로 만 수행하지만 작업은 작업으로 다른 수준에서 예약 될 수 있습니다. MOC는이를 좋아하지.
그러나 이제 프로그래밍 가이드에서 다음과 같은 내용이 있습니다.
동시성을 위해 사용할 수 있습니다. 간결함을 위해이 문서에서는 전체적으로 "스레드"를 사용하여 이들 중 하나를 참조합니다.
(스레드와 큐의 수준은 도움이되지 않지만 훌륭합니다). 따라서 / 블록 당 하나가 아닌 (직렬) 다수의 작업을 사용할 수 있습니다. Apple은 Core Data WWDC 세션에서 설명합니다.
하지만 ... 에서 NSManagedObjectContext문서, 애플 상태 :
[컨텍스트]는 기본 소유자가 자신을 할당하거나 큐라고 가정합니다. 이것은 메소드를 호출하는 방법에 의해 결정됩니다. 하나의 메시지에서 메시지를 초기화합니다.
이제 우리는 NSManagedObjectContext소유자가 누구인지 알 필요가 있는지 생각을 가지고 있습니다 . 이 대기열에서 실행되는 첫 번째 작업이 MOC를 만들고 나머지 작업을 사용할 수 있습니다. MOC에 대한 가정합니다.
이게 옳은 거니? 내가 주저하는 유일한 이유는 NSManagedObjectContext기사가 계속해서 다음과 같이 말하기입니다.
대신 영구 저장소 코디네이터에 대한 참조를 전달하고 수신 / 큐가 그로부터 파생 된 새 엔진을 생성해야합니다. NSOperation을 사용하는 경우 main (직렬 대기열의 경우) start (동시 대기열의 경우)에서 인스턴스를 또는합니다.
Apple은 이제 작업을 실행을 예약하는 대기열과 결합하는 것처럼 보입니다. 이 내 머리를 안고, 결국 모든 작업에 대해 새 MOC를 생성하기를 원하는지 궁금합니다. 내가 무엇을 놓치고 있습니까?
NSManaged ObjectContext 및 이와 관련된 모든 관리 ObjectContext는 단일 행위자 (스레드, 완성 된 행위자, 최대 동시성 = 1 NSOperationQueue)에 고정되어야합니다.
이 패턴을 제한 또는 격리라고합니다. (thread || serialized queue || NSOperationQueue with max concurrency = 1)에 대한 훌륭한 문구가 그대로 문서는 계속해서 "우리가 의미하는 경우 핵심 데이터 문서의 나머지 부분에 '스레드'를 사용합니다. 얻는 세 가지 방법 중 하나 "
한 사례에서 MOC를 만든 다음 다른 목적에서 사용하는 경우 MOC 참조를 두 사례에 노출하여 제한을 위반 한 것입니다. 단순합니다. 하지마. 개울을 건너지에서.
단어 및 GCD와 달리 -init는 NSOperation을 생성하는 하나의 SOperation을 실행합니다. -main은 NSOperation을 실행하는 언어에서 실행되는 이상한 문제가 있기 때문에 명시 적으로 NSOperation을 호출합니다. 눈을 찡 그리면 이해가 사용 가능합니다. -[NSOperation init]에서 MOC를 생성하면 NSOperation은 -main 메소드가 실행되기 전에 일찍 제한을 위반하여 사용자가 빠져 나갈 수 있습니다.
우리는 MOC 및 방식을 사용하는 것을 적극적으로 권장 / 지원 중단했습니다. 이론적으로는 옳은 일이 없습니다. 모든 사람들이 문제를 일으켜 한 곳에서 잠금을 해제하거나 "init는 어디에서 실행되고?"라는 필수 호출을 잊어 버렸습니다. 자동 릴리스 풀과 응용 프로그램 이벤트 루프, 실행 취소 관리자, 코코아 바인딩 및 KVO를 사용하면 MOC를 다른 곳으로 전달하려고 시도한 후 한층가 MOC에 대한 참조를 유지하는 방법이 너무 많습니다. 고급 Cocoa 개발자가 시작할 때까지 상상하는 것보다 훨씬 더 어렵습니다. 그래서 그것은 매우 유용한 API가 아닙니다.
문서는 제한을 명확하고 강조하기 위해 변경합니다. NSManagedObjectContext에서 -lock 및 -unlock을 사용하여 (a) 불가능하고 (b) 사실상 더 이상 사용하지 않고 추가로 멋지게 시도해야합니다. 코드가 이전처럼 잘 작동하기 때문에 문자 그대로 사용되지 않습니다. 그러나 그것을 사용하는 코드가 잘못되었습니다.
어떤 사람들은 하나의 인스턴스에서 MOC를 만들고-잠금을 호출하지 않고 다른 이름으로 전달했습니다. 그것은 합법적이지 않다. MOC를 기본적으로 사용하는 기본 구성은 항상 MOC의 기본 소유자입니다. 이것은 메인에서 생성 된 MOC에서 더 빈번한 문제가됩니다. 주 행사 MOC는 실행 취소, 메모리 관리 및 기타 MIST 응용 프로그램의 주 이벤트 루프와 상호 작용합니다. 10.6 MOC는 메인가되는 메인가 소유하는 것을 적극적으로 활용합니다.
많지 않은 특정 메시지에 바인딩됩니다. 귀하의 의무는 공용 API를 따르는 것입니다.
어떤 경우에는 해당하는 경우에 실행되는 경우에는 MOC를 공유 할 수 있습니다.
따라서 어떤 상황에서도 NSManagedObjectContext *를 둘 이상의 수준 (액터 등)에 노출하지 않습니다. 한 가지 모호성이 있습니다. didSave 알림에서 NSNotification *을 다른 용도의 MOC의 -mergeChangesFromContextDidSaveNotification : 메소드로 사용할 수 있습니다.
- 벤
당신이 옳은 것 변화합니다. 원하는 경우를 사용하는 경우를 원하는 경우가 있습니다. 큐를 사용하는 경우에는 원하는 큐가 큐에서 첫 번째 블록으로 선택합니다. 유일하게 혼란스러운 부분은 NSOperations에 관한 것입니다. NSOperations가 기본 프로그램 / 큐에 대한 실행되는 보증을 제공하지 않습니다. NSOperation이 모두 NSOperationQueue에서 실행되는 경우에도 작업간에 MOC를 공유하는 것이 안전하지 않습니다. 대체 설명은 문서가 혼란 스러울 뿐이라는 것입니다.
그것을 요 약하기 :
- 예를 사용하는 경우 원하는 경우 MOC를 만듭니다.
- GCD를 사용하는 경우 삽입되는 경우에 실행되는 첫 번째 블록에 MOC를 만듭니다.
- NSOperation을 사용하는 경우 NSOperation 내부에 MOC를 만들고 작업간에 공유하지 않고 연결합니다. 이것은 약간의 편집증적일 수 있습니다. NSOperation은 실행되는 기본 문법 / 큐를 보장하지 않습니다.
편집 : bbum에 따르면 유일한 실제 필요한 사항은 액세스를 필요로하는 것입니다. 즉, 작업이 모두 언급에 추가되고 대기열이 동시 작업을 허용하지 않는 한 NSOperations간에 MOC를 할 수 있습니다.
'ProgramingTip' 카테고리의 다른 글
| Zend Framework에서 레이아웃 파일을 전환하는 방법은 무엇입니까? (0) | 2020.12.05 |
|---|---|
| Facebook은 브라우저 주소 표시 줄에서 페이지의 소스 URL을 어떻게 다시 작성합니까? (0) | 2020.12.05 |
| 일대일 최대 수용 모드 : 전체 객체를 가져 오지 않고 getId () (0) | 2020.12.04 |
| SOAP 오류 또는 결과 개체? (0) | 2020.12.04 |
| 파일 열기 대화 상자를 사용하여 폴더를 선택할 수 있습니까? (0) | 2020.12.04 |