2014-04-20 5 views

답변

1

우선 DI를 사용하려면 문제를 피하고 스토리 보드를 사용하지 않는 것이 좋습니다.

사용하려는 경우 스토리 컨트롤러가보기 컨트롤러를 생성하므로 생성자 삽입이 불가능하므로 설정 주입을 사용한다고 가정합니다.

// .h 

@property (strong, nonatomic) NSManagedObjectContext *managedObjectContext; 

// .m 

- (NSManagedObjectContext *) managedObjectContext 
{ 
    if(_managedObjectContext == nil) 
    { 
     _managedObjectContext = [(AppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext]; 
    } 

    return _managedObjectContext; 
} 

예,이 뷰 컨트롤러 이후 DI 아닌 문맥을 찾는 대신 요청하고 있습니다 :

간단한 해결책은 다음과 같이 뷰 컨트롤러의 컨텍스트 게터에의 응용 프로그램 대리인의 컨텍스트를 얻을 수 있습니다 그것은 그렇게 나쁘지는 않지만 테스트에서 다른 컨텍스트를 쉽게 주입 할 수 있습니다.

또 다른 해결책은 UIStoryboard 하위 클래스에서 instantiateViewControllerWithIdentifier:을 덮어 쓰고 거기에 컨텍스트를 삽입하는 것입니다. 그러나 요청한보기 컨트롤러가 컨텍스트를 필요로하는지 확인하는 방법이 필요합니다 (respondsToSelector : @selector (setManagedObjectContext)) 그리고 스토리 보드 하위 클래스의 컨텍스트가 필요합니다 (위 코드 에서처럼 코드를 삽입하거나 액세스 할 수 있음). 유사한 접근법을보고 있지만 Typhoon을 사용하려면 this question을 확인하십시오.

마지막으로 말하자면보기 컨트롤러에서 컨텍스트를 삽입하면 거대한보기 컨트롤러가 생기기 쉽기 때문에 다른 모델 개체에 컨텍스트를 삽입 한 다음보기 컨트롤러에 컨텍스트를 주입합니다.

+0

조언 해 주신 점에 대해 이야기 게시판은 IOS 개발 (먼저 앱에서 시도)을 시작하는 좋은 방법 인 것 같았지만 DI의 한계라는 것을 알았습니다. 나는 내가 돌아가 이야기 게시판없이 다시 할거라고 생각한다. '다른 모델 개체에 컨텍스트를 삽입 한 다음 뷰 컨트롤러에 컨텍스트를 주입합니다.'라고 말하면 가장 좋은 것은 뷰 컨트롤러에 주입하기위한 컨텍스트와 함께 기본 쿼리/함수를 제공하는 클래스를 만드는 것입니다. –

+0

스토리 보드 정보는 맛의 문제이며, 사실 몇 가지 장점이 있지만 실제로는 그렇습니다 DI는 일을 좀 더 복잡하게 만듭니다. 어쨌든 태풍과 같은 도구가 그 질문에서 볼 수있는 것처럼 당신을 도울 수 있습니다. 그리고 컨텍스트 스터프에 맞으면 쿼리 및 기타 비즈니스 로직을 다루는 다른 클래스를 사용하여 뷰 컨트롤러를 더 얇게 유지하는 것이 좋습니다. – e1985