Other Cocoa Architectures

OSXDEV

모델-뷰-컨트롤러의 시각에서 , Cocoa 코어 애플리케이션 아키텍쳐는 응용프로그램의 뷰 레이어에 관여합니다. 주로 이벤트 처리와 드로잉의 기법을 다루며 응용프로그램이 자신을 사용자에게 제시하고 상호작용하도록 하는 방법을 위한 효율적인 모델을 제공합니다. 그러나 실제 응용프로그램에서 이들이 허공에 존재하는 것이 아닙니다. 다른 MVC 객체인 컨트롤러와 모델 객체가 드로잉과 이벤트 핸들링 기법에 중요성과 컨텐츠를 제공합니다.

Cocoa는 몇몇 다른 아키텍쳐를 소프트웨어 개발자들에게 제공합니다. 이들 아키텍쳐는 거의 대부분 컨트롤러와 (특히) 모델 객체외 연관되어 있습니다. 이들은 모델-뷰-컨트롤러 외의 다른 디자인 패턴, 특히 객체 모델링("Object Modeling"에 설명되 있습니다)에 기반하고 있습니다. 이들을 다른 공통점은 이들이 Cocoa 개발자의 삶을 더 편리하게 만들고자 한다는 점입니다.

[편집] Document Architecture

많은 프로그램들이 사용자가 문서를 생성하고 편집할 수 있도록 합니다. 문서는 동일한 유저 인터페이스의 창에 독특한 데이터의 집합체입니다. 워드 프로세서, 사진 편집 도구, 웹 브라우저는 문서기반 응용프로그램의 예입니다. 이들 응용프로그램은 비슷한 기능을 가지고 있습니다. 그들은 사용자가 새로운 문서를 생성하고, 파일로 저장하고, 나중에 이 문서를 다시 열도록 해줍니다. 문서기반 응용프로그램은 메뉴 항목을 검사하며 각 문서의 수정 상태를 모니터하고, 문서 창을 관리하고, (종료와 같은) 응용프로그램 전반적인 이벤트에 적절히 반응합니다. 종종 이들은 문서 데이터의 다른 내부 표현을 가질 수 있습니다.

Cocoa는 개발자들에게 아키텍쳐를 제공하여 이런 기능들을 갖춘 문서기반 응용프로그램을 구현하는데 필요한 노력을 줄여줍니다. 이 아키텍쳐의 필수적인 컴포넌트에는 세개의 Application Kit 클래스가 있습니다. NSDocument, NSDocumentController, NSWindowController 입니다. 문서기반 Cocoa 응용프로그램에서 이들 세 클래스의 객체들은 분명한 책임을 가지고 있으며 소유와 관리에 기반하여 서로 계단식의 관계를 연속적으로 가지고 있습니다. (Figure 7-1)

Figure 7-1  Ownership relationships among the document classes


다큐먼트 아키텍쳐에 기반한 Cocoa 응용프로그램은 하나의 NSDocumentController 객체를 갖습니다. 이 객체는 하나 혹은 그 이상의 NSDocument 객체를 소유하고 관리합니다. 이들 각각의 NSDocument 객체는 문서의 창과 결합됩니다. (한개의 문서가 다수의 창을 가질 수 있습니다.) NSWindowController 객체는 이 문서의 표현을 관리합니다.

Cocoa 다큐먼트 아키텍쳐의 이 세 종류의 객체는 각각 MVC 역할에 의해 지정된 책임을 갖습니다.

• NSDocumentController 객체는 응용프로그램의 문서를 관리합니다. 새로운 문서의 생성, 수정된 문서의 저장, 저장된 문서 열기를 시작하고 조정합니다. 전체 응용프로그램을 위한 MVC 패턴의 조정 컨트롤러의 역할을 수행합니다. NSDocumentController 객체는 문서 기반 응용프로그램에 자동으로 제공됩니다. 일반적으로 서브클래스 할 필요가 없습니다. NSDocumentController는 응용프로그램의 정보 프로퍼티 리스트(Info.plist)에 지정된 문서 타입 메타데이터로부터 문서를 관리하는데 필요한 정보를 가져옵니다. 이 메타데이터는 응용프로그램에게 응용프로그램이 읽고 쓸 수 있는 각 문서의 확장자, HFS 타입 코드, MIME 타입, 아이콘, (적용이 가능한 경우) NSDocument 서브클래스를 알려줍니다.
• NSDocument 객체는 문서의 모델 객체를 관리합니다. MVC 용어로, NSDocument 객체는 관리 책임이 모델 레이어로 옮겨져있는 컨트롤러인, 모델-컨트롤러입니다. NSDocument는 추상 클래스이고, 모델 객체에 캡슐화되어 있는 대로 문서의 데이터를 알고 있는 커스텀 서브클래스를 만들어야 합니다. 그 서브클래스의 인스턴스는 파일로부터 데이터를 읽고 그것으로부터 문서의 객체 모댈을 재생산하고, 문서의 현재 모델 객체 콜렉션을 파일로 저장할 수 있어야 합니다. 때때로, 문서 데이터의 내부 표현을 하나 이상 유지해야할 필요가 있을 수도 있습니다. NSDocument 객체는 하나 이상의 NSWindowController 객체를 소유하고 관리합니다.
• NSWindowController 객체는 창에서 문서의 표현을 관리합니다. MVC 용어로 NSWindowController 문서는 뷰-컨트롤러입니다. 문서 데이터가 표시되는 창을 관리하는 역할을 합니다. 간단한 응용프로그램의 경우 NSWindowController의 커스텀 서브클래스를 생성할 필요가 없을 수 있습니다. NSWindowController의 기본 인스턴스는 기본적인 창관련 작업을 처리하며 NSDocument 객체는 뷰 레이어의 지식을 통합합니다. 그러나 대부분의 경우 문서의 뷰 객체에 대한 지식을 NSWindowController 서브클래스에 추가해야 합니다. 이 서브클래스의 인스턴스는 주로 문서 nib 파일의 File's Owner입니다. 다수의 창을 갖는 문서는 각각의 창마다 다른 NSWindowController 객체를 몇개 가질 수 있습니다.

Xcode는 다큐먼트 아키텍쳐에 기반한 Cocoa 응용프로그램을 위한 프로젝트 템플릿을 제공합니다. 이 템플릿을 사용하여 프로젝트를 생성하면,(MyDocument라고 이름지어진) NSDocument 서브클래스를 요청된 메소드의 반쪽자리 구현과 함께 받게됩니다. 문서 nib 파일도 File's Owner가 MyDocument로 지정된 채로 받게됩니다.

[편집] Application Scriptability

AppleScript는 스크립트 언어이자 프로세스간 커뮤니케이션 기술로 많은 Macintosh 파워 유저들이 친숙합니다. 컴파일되고 동작시키면 AppleScript 스크립트는 응용프로그램에 명령을 보내고 데이터를 받아서 응용프로그램을 컨트롤합니다.

AppleScript 명령의 타겟이 되려면, 프로그램은 스트립팅 가능하도록 만들어져야 합니다. 스크립팅 가능한 프로그램은 자신의 행동과 데이터가 AppleScript로 생성된 프로세스간 메시지, 즉 Apple 이벤트에 반응하도록 합니다. 생산-품질 응용프로그램은 보통 스크립팅 가능합니다. Automator 프로그램의 스크립터와 유저를 포함하여 자신의 응용프로그램이 제공하는 기능을 최대한 많은 사람에게 제공하길 원할 수 있습니다.

Cocoa는 스크립팅 가능한 응용프로그램을 위한 런타임 지원을 제공합니다. 응용프로그램의 스크립팅 가능성 정보가 처음 필요한 때, Application Kit은 그 정보를 로드하고 지원되는 명령을 위한 Apple 이벤트 핸들러를 자동으로 등록합니다. 응용프로그램이 등록된 명령에 Apple 이벤트를 받으면 Application Kit은 스크립트 명령 객체를 인스턴스화하고, 응용프로그램의 스크립트 가능성 정보로부터 얻은 정보로 초기화시킵니다. 이 정보는 응용프로그램 내에서 명령이 수행되어야 하는 스크립팅 가능한 객체를 찾도록 해줍니다. Application Kit은 그 후 명령을 수행하고 스크립팅 가능한 객체는 요청받은 작업을 수행합니다. 만일 이 객체가 값을 반환하면, Application Kit은 그 값을 Apple 이벤트에 집어넣고 원래 스크립트로 반환합니다.

이 런타임 지원이 효과적이려면 응용프로그램이 스크립팅 가능해야합니다. 이 작업은 몇몇 요소로 구성되어 있습니다.

• 응용프로그램의 스크립팅 가능성 정보를 제공해야 합니다. 스크립팅 가능성 정보는 스크립트가 응용프로그램과 그 객체를 타겟으로 삼는데 사용할 용어를 지정합니다. 또한 그 용어를 위한 지원을 응용프로그램이 구현한 방식에 대한 정보도 포함하고 있습니다. 스크립트 가능성은 두가지 포맷중의 하나로 제공합니다. 더 선호되는 포맷은 확장자가 .sdef이기 때문에 sdef 포맷이라고도 불리는 XML 기반의 스크립팅 정의입니다. 두번째로 좀 더 오래된 포맷은 스크립트 스위트 파일과 스크립트 용어 파일 두개의 프로퍼티 리스트파일로 구성되어 있습니다.

두개의 포맷은 동일한 스크립팅 가능성 정보를 포함하고 있습니다. 그들은 스크립트에서 사용되는 용어를 정의하고 AppleScript와 Cocoa가 AppleScript 명령을 수행하는데 필요로 하는 클래스, 명령, 상수, 그리고 그 밖의 정보를 지정하는 것으로 응용프로그램 내에서 스크립팅 가능한 객체를 설명합니다.

• 스크립팅 가능성을 지원하는데 필요한 클래스나 메소드를 구현해야 합니다. Cocoa는 Standard 스위트에서 (get, set, window, document와 같은)흔히 쓰이는 명령과 다른 용어 지원을 포함합니다. (AppleScript에서 용어는 스위트에 모여있는 관련된 작업들과 연관되어 있습니다.) 또한, Cocoa 텍스트 시스템의 객체에 작업을 스크립팅 작업을 수행하도록 Text 스위트도 지원합니다. 만일 프로그램에 Standard나 Text 스위트에 정의된 명령으로 수행할 수 없는 스크립팅 작업이 있다면, 추가적인 명령 클래스를 정의해야 합니다. 거기에 각 스크립팅 클래스마다 객체-지정 메소드를 구현해야만 합니다. 이 메소드는 그 클래스의 객체를 설명하고 응용프로그램의 객체 계층 내에서 그 객체를 찾습니다.
• 응용프로그램의 모델과 컨트롤러 객체들을 적절히 디자인해야 합니다. 스크립팅 가능한 Cocoa 응용프로그램은 반드시 프로그램의 객체에 정해진 디자인 역할을 부여하는 MVC 디자인 패턴에 따라 디자인되어야 합니다. 프로그램의 모델 객체는 일반적으로 스크립트 가능성을 제공하는 객체입니다. (컨트롤러 객체도 스크립트 가능한 객체가 될 수도 있습니다.) 응용프로그램에서 스크립팅 가능한 클래스는 키-밸류 코딩을 준수해야합니다. KVC는 객체 프로퍼티를 키를 사용하여 간접적으로 수집하고 설정하도록 해줍니다. 런타임 시, 명령 객체는 KVC를 사용하여 작업을 수행한 스크립팅 가능 객체를 찾습니다.

(기본적으로 키인)프로퍼티의 이름을 프로퍼티를 담는 인스턴스변수나 그 프로퍼티를 얻어오거나 설정해주는 클래스의 액세서 메소드에 통합하여 KVC 준수를 구현합니다. 스크립팅 가능한 객체(와 보통 모델)의 클래스를 디자인 할 때, 응용프로그램의 스크립팅 가능성 정보에 이들 객체의 키, 이들 객체의 스크립팅 속성, 그들이 포함하는 클래스를 지정하여 줄 수 있습니다. KVC가 기반하고 있는 디자인 패턴에 대한 더 많은 정보는 “Object Modeling” 에서 찾을 수 있습니다.


 스크립팅 지원과 별개로 Cocoa는 응용프로그램이 시스템의 다른 프로세스로부터 받는 특정 이벤트를 자동으로 처리합니다. "Handling Apple Events"에서 애플 이벤트와 Cocoa의 그 이벤트 처리하는 방식에 대해 설명합니다.

[편집] Core Data

Core Data는 Cocoa 프레임웍으로 다양한 파일 형태로 영속 저장 지원 기능을 포함하며 객체 그래프를 관리하기위한 기반 구조입니다. 객체-그래프 관리는 작업 취소와 다시하기, 타당성 조사, 그리고 객체 관계의 일치성 보장과 같은 기능을 포함합니다. 객체 영속성은 Core Data가 모델 객체를 영속 저장소에 저장하고 필요할 때 그들을 불러오는 것을 의미합니다. Core Data 프로그램의 영속 저장소는 데이터가 아카이브되는 궁극적인 형태로 XML 파일에서부터 SQL 데이터베이스까지 가능합니다. Core Data는 관계 데이터베이스의 프론트엔드로 동작하는 응용프로그램에 적절하지만 어느 Cocoa 프로그램이든Core Data의 장점을 활용할 수 있습니다.

Core Data의 주 컨셉은 관리된 객체(managed objects) 입니다. 관리된 객체는 단순히 말하면 Core Data에 의해 관리되는 모델 객체인데, 반드시 NSManagedObject나 그 서브클래스의 인스턴스여야만 합니다. Core Data 프로그램의 관리된 객체는 관리된 객체 모델 이라고 불리는 스키마를 사용하여 기술됩니다. (Xcode는 이들 스키마를 생성하도록 돕는 데이터 모델링 툴을 포함하고 있습니다.) 관리된 객체 모델은 응용프로그램의 (개체:entity 라고도 불리는)관리된 객체의 기술(description)을 포함합니다. 각 기술은 개체의 애트리뷰트, 다른 개체와의 관계, 개체의 이름이나 대표하는 클래스와 같은 메타데이터를 지정합니다.

Core Data 프로그램을 돌리면, 관리된 객체 컨텍스트라고 알려진 객체가 관리된 객체의 그래프를 책임집니다. 그래프 내의 모든 관리된 객체는 관리된 객체 컨텍스트에 등록되어져야만 합니다. 컨텍스트는 응용프로그램이 그래프에 객체를 더하거나 제거할 수 있도록 합니다. 또한 이들 객체에 가해지는 변화도 감지하여 작업 취소와 다시하기 지원을 제공합니다. 관리된 객체에 가해진 변화를 저장할 준비가 되면, 관리된 객체 컨텍스트는 이들 객체가 유효한 상태에 있는지 확인합니다. Core Data 프로그램이 외부 데이터 저장소로부터 데이터를 가져오고자 할때, 가져오기(fetch) 요청(범주를 지정하는 객체)을 관리된 객체 컨텍스트에 보내게 됩니다. 컨텍스트는 저장소로부터 요청에 맞는 객체를 찾아 자동으로 등록한 후, 그 객체를 반환해줍니다.

관리된 객체 컨텍스트는 영속 스택이라고 불리는 Core Data 객체의 하부 콜렉션으로의 게이트웨이 기능도 수행합니다. 영속 스택은 응용프로그램의 객체와 외부 데이터 저장소 사이를 중개합니다. 스택은 영속 저장소와 영속 저장소 코디네이터 이 두 개의 다른 객체로 구성됩니다. 영속 저장소는 스택의 맨 밑바닥에 있습니다. 외부 저장소, 예를 들어 XML 파일에 데이터와 관리된 객체 컨텍스트안의 해당하는 객체 사이를 매핑합니다. 그러나 관리된 객체 컨텍스트랑 직접 상호작용하지는 않습니다. 스택에서 영속 저장소 위에는 영속 저장소 코디네이터가 있는데, 하나 혹은 그 이상의 관리된 객체 컨텍스트에 외양을 제공하여 그 아래에 위치한 다수의 영속 저장소가 단 하나의 종합 저장소로 보이게 해줍니다. Figure 7-2는 Core Data 아키텍쳐에서 객체 사이의 관계를 보여줍니다.

Figure 7-2  Managed object contexts and the persistence stack


Core Data는 NSDocument의 서브클래스이며 Core Data와 다큐먼트 아키텍쳐를 통합하도록 도와주는 NSPersistentDocument 클래스를 포함하고 있습니다. 영속-문서 객체는 자신의 영속 스택과 관리된 객체 컨텍스트를 생성하며 문서를 외부 저장소에 매핑합니다. NSPersistentDocument 객체는 문서 데이터를 읽고 쓰는 기본 NSDocument 메소드 구현을 제공합니다.