MVC 디자인 패턴 용 iOS 프로젝트 구성

Question

iPhone 용 멀티 뷰 앱에서 현재 작업 (VIEW) 설정과 전환 (CONTROLLER?)이 잘 작동합니다. 이제 실제 프로그램 데이터 (MODEL)에 대한 개체를 추가하고 싶습니다.

내 질문 : 모델 뷰 컨트롤러 (MVC) 디자인 패턴을 준수하도록 데이터를 구조화해야합니까? 데이터 구조를 구현하기 위해 별도의 클래스를 만들어야하며 컨트롤러 클래스는 뷰에서 메시지를 전달할 수 있지만 검토해야 할 다른 조직 고려 사항이 있습니까? 특히 코코아 터치, Xcode, 또는 iOS에 특히 그렇습니까?

기타 정보 : 사전 녹음 된 오디오 및 사용자 생성 오디오의 재생 또한 필수적입니다. 나는 이것들이 모델 요소라는 것을 알고 있습니다. 그러나 그것들이 "V"와 "C"에 얼마나 관계가 있는지는 아직 모호합니다. 나는 사용자 액션이 오디오 재생을 필요로 할 때 컨트롤러가 적절한 사운드를 준비하기 위해 MODEL에 메시지를 전달해야한다고 생각하지만 재생의 규정이 정확히 어디에 있어야합니까? 내가 상상하는 ViewController와는 별도로 "PlayerController"에서?

많은 MVC 노 베리를 보내 주셔서 감사합니다.

Answer 1

Caleb는 문제에 대해 어떻게 생각하는지에 대한 좋은 소개와 개요를 제공합니다. - 실제 오디오 데이터를 유지하기위한 책임

• 클립 (M) : 특정 경우에는 여기에서 당신이 당신의 설명을 준 수있는 것이다 조각의 일부입니다.데이터를 해석하는 방법과 주어진 정보를 알고 있지만 실제로는 아무 것도 재생하지 못합니다.

• 플레이어 (V) - 실제로 스피커에서 클립을 재생합니다. 예, MVC에 보기입니다. 오디오는 또 다른 종류의 프리젠 테이션입니다. 즉, UIView의 하위 클래스 였으므로 "PlayerView"라고 부르지 않을 것입니다.

• PlayerView (V) - Player의 화면 표현입니다. 클립에 대해 아는 것이 없습니다.

• ClipManager (C) - 등 시스템의 모든 클립을 추적하고, 네트워크에서 그들을 가져 오는 추가 및 캐시에 제거 관리 할 객체,

• PlayerViewController (C) - ClipManager에서 클립을 검색하고 Player와 PlayerView를 좌표로 표시하고 재생하며 다른 UI 요소 (예 : "뒤로 단추"등)를 조정합니다.

이것은 이론적 인 오디오 플레이어 응용 프로그램을 어떻게 분해 할 수 있는지 예입니다. 그것을하기위한 많은 올바른 MVC 방법이 있지만 이것은 그것에 대해 생각하는 한 가지 방법입니다.

Answer 2

Lord John Worfin (그리고 그 사람 앞에서 누군가) : "캐릭터는 당신이 어둠 속에있는 것"이라고 말했다. 글쎄, 모델은 아무도보고 있지 않을 때 애플리케이션이 무엇인지를 보여줍니다. 화면에 표시되는 방식과 관계없이 앱의 동작 방식을 정의하는 데이터 및 로직입니다.

응용 프로그램에 명령 줄 인터페이스를 추가한다고 가정 해보십시오. 여전히 데이터 관리에 동일한 구조를 사용하고 데이터를 기준으로 정렬, 선별 및 계산 논리를 동일하게 유지해야합니다. 사용자가 앱을 보거나 앱과 상호 작용하는 방식과 관계없이 중요하거나 유용한 상태로 유지되는 앱의 코드가 모델입니다.

모델은 매우 간단하고 표준 개체로만 구성 될 수 있습니다. iOS 앱은 종종 숫자를 처리하는 것보다 데이터를 검색, 저장 및 표시하는 데 더 많은 역할을하므로 사전의 배열 또는 몇 가지 수준의 사전 계층 구조 인 모델을 사용하는 것은 드문 일이 아닙니다. Core Data의 NSManagedObject 클래스를 살펴보면 NSMutableDictionary와 비슷한면이 있습니다. 따라서 표준 개체를 사용하는 것이 적절할 경우 두려워하지 마십시오.

그렇다면 자신 만의 모델 객체를 만들 수도 있습니다. 데이터에 적용하려는 특정 요구 사항이 있거나 데이터에서 정보를 얻을 수 있기를 원하는 경우 유용합니다.

초보자는 각 컨트롤러가 모델에 어떻게 액세스하는지 궁금해합니다. 일부 사람들은 싱글 톤 패턴을 사용하여이를 옹호합니다. 주로 단일 공유 된 전역 적으로 액세스 가능한 객체를 제공하기 때문입니다. 나는 이것을 추천하지 않는다. 대신 앱 위임과 같은 일부 고급 객체를 모델을 생성 /로드 (많은 개별 객체의 그래프 일 가능성이 있음)하고 필요로하는보기 컨트롤러에 모델에 대한 포인터를 제공하십시오. 이러한 컨트롤러가 다른 뷰 컨트롤러를 생성하면 자식 컨트롤러에 대한 모델 (또는 그 일부)에 대한 포인터를 다시 제공 할 수 있습니다.

도움이 되었기를 바랍니다.