UIApplicationDelegate에서 ManagedObjectContext를 가져 오는 Apple 설명서가 불량한 이유는 무엇입니까?

Question

UIApplicationDelegate에서 ManagedObjectContext를 가져 오는 대신 UIViewController를 생성 할 때 왜 ManagedObjectContexts를 전달해야하는지 궁금하십니까?

문서를 보면 응용 프로그램이 더 엄격 해지지 만 어떤 패턴을 사용해야하는지의 뉘앙스를 보지 못하고 있다고합니다.

감사합니다.

Answer 1

방을 칠하는 것처럼 몇 가지 작업을 수행 할 것을 요청한다고 상상해보십시오. 방금 페인트 칠을하라고하면 다음과 같은 질문을 많이 걸어야합니다.

• 어느 방을 사용합니까?
• 페인트는 어디에 있습니까?
• 브러쉬 위치는 어디입니까?
• 드롭 클로스를 사용해야합니까?

요약하면 내 도움없이 작업을 완료 할 수 없습니다. 매번 저를 의지해야한다면, 당신은 매우 유연한 화가가되지 못할 것입니다. 그 문제를 다루는 한 가지 방법은 처음에 필요한 모든 것을 제공하는 것입니다. "방에 페인트 칠하기"대신 "이 방석과이 브러시를 사용하여 방 번호 348을 페인트하고 방울 주걱으로 귀찮게하지 마십시오."라고 말할 것입니다. 이제는 필요한 모든 것을 갖추었고 더 이상의 도움 없이도 작업 할 수 있습니다. 당신은 더 이상 융통성있는 직원입니다. 왜냐하면 당신은 더 이상 의존하지 않기 때문입니다.

보기 컨트롤러 (및 일반적으로 객체)에도 똑같은 작업이 적용됩니다. 애플리케이션 위임자와 같은 특정 객체에 의존하게하는 것보다 필요한 모든 것을 제공하는 것이 좋습니다. 관리 대상 컨텍스트 만이 아니라 업무 수행에 필요한 모든 정보를 제공합니다.

Answer 2

이것은 주로 UIApplication의 모든 것을 잡는 대신 dependency injection을 UIViewController와 함께 사용하기 때문에 발생합니다. 이는 참조 해킹으로 가득 찬 대신 대리인을 깨끗하게 유지합니다. 뷰와 모델 사이의 조정을 위해

1. 모델 (만보기 로직)

2. 보기 컨트롤러

3. 컨트롤러 (:

   이는 MVC 패턴을 유지하기 위해도)

Answer 3

나는이 파와 동의하지 않는 경향이 있습니다. 튼튼한.

우선 코어 데이터를 구현 세부 사항으로 처리하려고 시도합니다. 구현 세부 사항은 좋은 외관 뒤에 숨겨져 있어야합니다. 외관은 내 모델 객체에 대해 공개하는 인터페이스입니다. 예를 들어 두 개의 모델 객체가있는 경우; Cource 및 Student이면 모든 리소스에 많은 학생을 보유 할 수 있습니다. 컨트롤러가 술어를 설정하고 설명자를 정렬해야하는 의무를 맡기를 원하지 않고 특정 클래스의 학생 목록을 얻으려고 모든 핵심 데이터 고리를 건너 뛰고 싶습니다. 모델에이 문제를 드러내는 완전히 유효한 방법은 다음과 같습니다. 그런 다음 Model 클래스에서 추악한 것들을 구현합니다. 핵심 데이터의 모든 복잡한 세부 사항을 숨기고 관리 대상 객체 컨텍스트를 전달할 필요가 없습니다. 하지만 어떻게 소스를 찾을 수 있을까요, 어딘가에 시작해야합니까? 예, 그렇습니다 만 컨트롤러에 표시 할 필요는 없습니다. 이와 같은 메소드를 추가하는 것도 매우 합리적입니다.

@interface Cource (CourceAccess) 
+(Cource*)caurceByID:(NSString*)courceID; 
+(NSArray*)allCources; 
+(NSArray*)courcesHeldByTeacher:(Teacher*)teacher; 
@end 

이렇게하면 컨트롤러 간의 종속성을 최소화하는 데 도움이됩니다. 모델과 컨트롤러 간의 의존성을 줄입니다.

-(id)initWithManagedObjectContext:(NSManagedObjectContext*)moc 
          student:(Student*)student; 

: 나는 CourceViewController이 있고 StudenViewController 내가 외관 뒤에 코어 데이터의 세부 사항을 숨기고뿐만 아니라 관리되는 개체 컨텍스트 주위에 통과 한 후 나는이 같은 지정된 초기화로 끝날 것입니다 싶어하지 않았다입니다 가정

는 반면 좋은 좋은 외관과 나는이와 끝까지 :

-(id)initWithStudent:(Student*)student; 

의존성 주입에 찬성, 외관 뒤에 종속성을 최소화도 훨씬 쉽게 내부 구현을 변경할 수 있습니다. 관리 대상 객체 컨텍스트를 전달하면 각 컨트롤러가 기본 작업을 위해 자체 논리를 구현할 수 있습니다. 예를 들어 studentsSortedByName 메소드를 가져옵니다. 처음에는 성/이름별로 정렬 할 수 있습니다. 나중에 성/이름 정렬로 변경하면 학생을 분류 한 모든 컨트롤러로 이동하여 변경해야합니다.좋은 외관 방법은 한 가지 방법으로 변경해야하며 모든 컨트롤러는 자동으로 무료로 업데이트를받습니다.

Answer 4

Apple Docs는 가장 널리 적용 가능하고 지속 가능한 디자인 패턴을 육성하려고 노력합니다. 종속성 주입은 가장 유연하고 확장 가능하며 재사용 가능하고 유지 보수가 가능한 디자인을 허용하기 때문에 선호됩니다.

응용 프로그램이 복잡 해짐에 따라 응용 프로그램 대리인의 컨텍스트를 파킹하는 것과 같은 준 싱글 톤을 사용하면 세분화됩니다. 보다 복잡한 응용 프로그램에서는 여러 상점을 여러 상점에 묶어 둘 수 있습니다. 서로 다른 시간에 다른 컨텍스트의 데이터를 표시하도록 동일한 뷰 컨트롤러/뷰 쌍을 원하거나 다른 스레드/작업에서 다중 컨텍스트로 끝나기를 원할 수 있습니다. 당신은 모든 애플 리케이션 델리게이트에서 그 맥락을 쌓을 수 없습니다.

단일 컨텍스트가있는 간단한 응용 프로그램을 사용하는 경우 응용 프로그램 대리인과 유사 싱글 톤을 사용하면 잘 작동 할 수 있습니다. 나는 즉시 몇 가지 작은 애플 리케이션에 즉각적인 문제없이 사용했지만 두 가지 애플 리케이션에서 확장 성 문제를 겪었습니다.

사용할 패턴은 운송 제약 조건에 달려 있으며 진화 응용 프로그램의 전체 수명주기를 가장 잘 추측 할 수 있습니다. 그 작은 하나의 샷 애플 리케이션, 다음 응용 프로그램 대리인 준 싱글 톤 괜찮 작동합니다. 앱이 더 복잡하고 복잡해 지거나 기존 구성 요소를 재사용 할 수있는 다른 관련 앱을 생성 할 수있는 경우 종속성 삽입을 사용하는 것이 좋습니다.