MVC en una aplicación basada en documentos de cacao

Question

Voy a través de una refactorización y reorganización de mi solicitud en este momento. Me he dado cuenta de que algunos de la separación entre los modelos y puntos de vista, y sus controladores ha disminuido y deseo de hacer algo de limpieza.

Tengo varias clases clave utilizados en mi aplicación: NSPersistentDocument, NSWindowController, y una clase de modelo

.

Los clase actúa NSPersistentDocument como un "modelo de controlador"; posee una instancia de la clase del modelo, y gestiona todas las interacciones con el modelo.

La clase NSWindowController actúa como un "vista-controlador"; que posee la ventana principal, y gestiona las interacciones de los puntos de vista dentro de la ventana principal. Esta clase es también el propietario del archivo para el archivo de la semilla en el que se define la ventana.

El problema que veo aquí es que no tengo un verdadero "controlador". Mi diseño actual obliga al modelo de controlador y vista-controlador a saber el uno del otro. No hay ningún objeto meditating entre los dos, y debido a esto, mi modelo y la vista no están claramente separados, lo que hace que soporta múltiples vistas o modelos de un problema.

Me gustaría para mover la funcionalidad de ambos de mis controladores existentes en una nueva clase "controlador" que actuaría como un controlador de entre el modelo de controlador y vista-controlador. Al final, esto sigue siendo sólo el patrón de diseño MVC, con sólo un poco más estructura.

Sin embargo, estoy teniendo dificultades para encontrar la manera de que esto encajar en la arquitectura de aplicaciones basadas en el documento de cacao.

La pregunta más grande que tengo es dónde y cómo se creó este nuevo objeto controlador? ¿Cómo encaja esto en la arquitectura de cacao? ¿Estoy luchando contra la arquitectura de cacao, y hay una mejor manera de hacer esto?

Gracias.

Answer 1

grandes instintos en tener un "controlador de modelo" y un "controlador de vista". Esa es una muy buena taxonomía mental how de la M y los V generalmente cuelgan juntos. Pero todavía se puede tener la pura "C" en el MVC para atar toda la operación en conjunto, como se nota.

Si usted está hablando de un controlador, para la aplicación: Piense en la (gran-C) como el controlador cosa que surge de function-- principal () de la aplicación en más viejos tutoriales de cacao este objeto se llama a menudo AppController. Podría ser el delegado de UIApplication, o no, pero si no es así, se debe considerar la creación de un controlador de este tipo maestro en el método applicationDidFinishLaunching: del delegado de la aplicación en su proyecto. AppController que a continuación puede configurar (y propia) los objetos del modelo y establecer (y propia) del controlador de vista raíz, de la que sus resortes de interfaz de usuario.

Si usted está hablando de algún componente mediadora que hay varias instancias de, una para cada modelo / vista "par" en una arquitectura de documento, a continuación, sólo hacer algo como eso también. DocumentController es el tipo de nombre que desee, a pesar de cacao tiene una de las ya que puede o no reflejar el tipo de funcionalidad que necesita. "DocumentManager" es otro nombre del candidato.

Answer 2

Parece que usted necesita para recoger una copia de cacao Diseño , responde a estas preguntas y algo más.

Capítulo 2 trata el patrón MVC usando un ArrayController como el controlador modelo (en lugar del documento persistente modelo de controlador que esté utilizando).