Cocoa / Cocoa Touch 애플리케이션에서 "코어 데이터 스택"을 배치 할 위치

Cocoa / Cocoa Touch 애플리케이션에서 "코어 데이터 스택"을 배치 할 위치

---

iPhone Core Data Template에서 Apple은 App Delegate에 Core Data Stack을 배치합니다.

그러나 나의 초기 성향은이 코드를 코어 데이터 스택의 관리를 담당하는 자체 클래스로 옮기는 것입니다.

일반적으로이 기능을 자체 클래스 내에 캡슐화합니까 아니면 App Delegate에 남겨 두십니까?

---

요약 : Core Data 스택을 관리하기 위해 싱글 톤을 생성 할 필요가 없습니다. 실제로 그렇게하는 것은 비생산적 일 수 있습니다.

Core Data 스택은 애플리케이션 델리게이트에 의해 생성됩니다. 그러나 중요한 것은 모든 예제에서 알 수 있듯이 스택 (주로 관리되는 개체 컨텍스트)이 stack (*)에서 직접 검색 되지 않는다는 것 입니다. 대신 컨텍스트가 첫 번째 뷰 컨트롤러로 전달되고 컨텍스트 또는 관리되는 객체의 컨텍스트가 하나의 뷰 컨트롤러에서 다음 컨트롤러로 전달됩니다 ( 핵심 데이터 스택 액세스에 설명 됨 ). 이것은 iPhone 모든 애플리케이션의 기본 패턴을 따릅니다. 데이터 또는 모델 컨트롤러를 한 뷰 컨트롤러에서 다음 컨트롤러로 전달합니다.

여기에 설명 된 싱글 톤의 일반적인 역할은 모델 컨트롤러입니다. Core Data에서 관리되는 개체 컨텍스트는 이미 모델 컨트롤러입니다. 또한 필요한 경우 스택의 다른 부분에 액세스 할 수있는 기능도 제공합니다. 또한 문서에 설명 된 일부 상황에서는 다른 컨텍스트를 사용하여 개별 작업 집합을 수행 할 수 있습니다. 따라서 뷰 컨트롤러의 적절한 통화 단위는 일반적으로 관리되는 개체 컨텍스트이고 그렇지 않으면 관리되는 개체입니다. 스택을 관리하고 컨텍스트를 검색하는 싱글 톤 객체를 사용하고 전달하면 일반적으로 불필요한 수준의 간접 지정이 발생하고 최악의 경우 불필요한 애플리케이션 강성이 발생합니다.

(*) 다음을 사용하여 컨텍스트를 검색하는 예는 없습니다.

[[UIApplication delegate] managedObjectContext];

---

핵심 데이터 관리를 할 수있는 싱글 톤 클래스가 있으며 앱 델리게이트에 남겨 두지 않습니다. 차라리 특정 개체 가져 오기 등과 같은 편의성에 필요할 수있는 메서드로 앱 대리자 클래스를 어지럽히 지 않습니다

---

다음과 같은 이유로 핵심 데이터 논리를 앱 대리자에 남겨 둡니다.

1) 다른 클래스에서이 코드를 이동하는 데있어 실질적인 이점은 없습니다. 위임 개념은 핵심 데이터 모델이 실제로 애플리케이션의 기본 부분이기 때문에 앱 델리게이트가 처리하는 핵심 데이터 로직에 의해 완벽하게 충족됩니다.

2) Apple 샘플을 포함하여 내가 본 모든 샘플 코드에서 핵심 데이터는 App 델리게이트에 의해 처리됩니다.

3) 핵심 데이터 책에서도 앱 델리게이트가 핵심 데이터 관련 코드를 처리하도록하는 것이 일반적입니다.

4) 개인적으로 핵심 데이터에 대한 임시 수업을 통해 가독성이나 다른 것이 실제로 향상되었다고 생각하지 않지만 이것은 개인적인 취향의 문제이며 여기서 어떤 접근 방식이 가장 좋은지 논쟁하지 않을 것입니다. 나에게는 기능을 유지하면서 단순함이 중요합니다.

---

귀하의 경우에 제가 스스로에게 물어볼 질문은 "핵심 데이터 스택은 누구에게 속합니까?"입니다. 데이터 자체는 실제로 응용 프로그램의 영역입니다. (한 번에 여러 문서로 작업 할 수있는 애플리케이션이있는 Mac의 CF Core Data이므로 Core Data 스택은 각 문서에 속합니다.)

모든 Cocoa / Cocoa Touch 애플리케이션에서 App Delegate는 일반적으로 애플리케이션의 동작을 사용자 지정하는 데 선호되는 수단이므로 Core Data 스택의 자연스러운 위치입니다.

자, 제가 생각하는 문제는 다음과 같은 것을 지속적으로 작성하는 것이 잘못되었다고 생각한다는 것입니다.

NSManagedObjectContext *context = [(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];

이 경우 일반적으로 수행하는 작업은 다음과 같은 함수 (메서드가 아님)를 작성하는 것입니다.

NSManagedObjectContext *UIAppManagedObjectContext() {
    return [*(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
}

나는 NSPersistentStoreCoordinator및 NSManagedObjectModel. 이 모든 것을 App Delegate의 .h / .m 파일에 넣었습니다. 이것들도 애플리케이션 수준 개체이기 때문입니다.

---

나는 이것을 새로운 대답에 나열 할 것입니다. (이를 위해 이전 FJSCoreDataStack 클래스를 폐기했습니다)

이것을 처리하는 나의 새로운 방법은 NSManagedObjectContext에 카테고리를 사용하는 것입니다. 다음 클래스 메서드를 추가했습니다.

+ (NSManagedObjectContext *)defaultManagedObjectContext;
+ (NSManagedObjectContext *)scratchpadManagedObjectContext;
+ (NSManagedObjectModel *)managedObjectModel;
+ (NSPersistentStoreCoordinator *)persistentStoreCoordinator;
+ (NSString *)applicationDocumentsDirectory;

이것은 내 앱 델리게이트에서 모든 것을 유지하고 사용하기로 선택하면 싱글 톤 액세스를 제공합니다. 그러나 여전히 App Delegate의 종속성 주입을 사용합니다 (mmalc가 말했듯이 내 코드에 비 유연성을 도입 함). 모든 "Core Data Stack"코드를 NSManagedObjectCOntext 범주로 이동했습니다.

특히 멋진 "스크래치 패드 컨텍스트"메서드가 있기 때문에 참조를 전달하는 것을 좋아합니다. 이것은 "defaultManagedObjectContext"에 커밋하지 않았기 때문에 내 뷰 컨트롤러를 유연하게 유지합니다.

또한 iPhone 세계의 대화와 관련이 있습니다 (아키텍처에 영향을 미칠 수 있음) : NSFetchedResultsController 및 NSFetchRequests 구성

---

I'm in favour of having the app delegate know where the model starts, and having the model know where the Managed Object Context is. The Core Data-"ness" of the model seems like an implementation detail of the model to me, the controller classes (like the app delegate) should just ask "give me this information about the model" and the model should know how to answer that question. Therefore having a Core Data object available through a controller object seems like a leaky abstraction.

참고URL : https://stackoverflow.com/questions/1267520/where-to-place-the-core-data-stack-in-a-cocoa-cocoa-touch-application