2010-02-08 12 views
15

Me he estado preguntando por un tiempo, después de preguntar a diferentes personas y sin que ninguno de ellos proporciona lo que yo llamaría un "por lo menos un poco respuesta concreta":En MVC, ¿dónde coloca referencias a sus clases modelo?

Pregunta:

Cuando, en una aplicación iPhone debería una aplicación mantener las referencias a sus Clases de modelos (utilizando el enfoque MVC)?

En las aplicaciones de iPhone (y Cocoa) tenemos lo que llamamos el "delegado de la aplicación", que básicamente inicia nuestra aplicación y en nuestros controladores, también maneja los eventos de UITouch.

¿La aplicación Delegate es un controlador? una clase modelo? ninguno de los dos? Creo que no saber eso también hace que sea confuso saber dónde poner las referencias del modelo.

Ejemplo:

Usted tiene el Delegado de aplicación, que el delegado contiene una referencia al controlador de vista de su aplicación. Si mi aplicación usaría la clase de modelo A (que es una clase de daemon de servidor web) y una clase B que almacena datos consultados por ese servidor web.

¿Dónde guardarían las referencias a A y B? (App Delegate? View Controller? Both?)

Aquí hay muchas opciones, pero a modo de ejemplo, me gustaría saber cómo usarían mvc para armar esta aplicación que solo usa una Vista.

Respuesta

7

Es tentador poner todo en AppDelegate, pero si comienza a hacer esto, entonces su AppDelegate estará lleno de hacks de referencia. Si usted está haciendo una estricta MVC, entonces no debería tener 3 cosas:

  • un modelo
  • Una Vista Controlador (Sólo para la vista lógica)
  • un controlador (Para la coordinación entre la vista y el modelo)

Así que, por ejemplo, tengo un modelo Foo y un controlador Foo. Tendría:

  • Foo.m (Modelo)
  • FooViewController.m (Muestra una Foo)
  • FooController.m (controla la lógica)

Y, por último, para responder a sus pregunta, almacenaría mis referencias a Foo en el Foo Controller. Me gusta usar singletons para mis controladores, pero así soy yo. Si usted hace uso de un producto único, sólo puede hacer algo como esto: [[FooController sharedInstance] listOfFoos] para obtener de su Foo

+1

Si solo trabaja con archivos .xib para GUI (a través de Interface Builder), su "FooViewController.m (Muestra un Foo)" (que solo contiene lógica de vista) sería entonces equivalente FooViewController.xib ?? – Goles

+0

Esencialmente sí. Si usa un xib, aún tendrá un archivo .m de respaldo, y ese archivo es el controlador de vista – coneybeare

1

Tradicionalmente, el controlador crea el modelo y luego inicializa la vista con ese modelo. Luego, el controlador escucha los cambios en el modelo y ve y coordina el flujo del programa a través de este. Esa sería mi respuesta genérica, tal vez las cosas en la práctica serían diferentes para el desarrollo de iPhone.

1

¿Dónde, en una aplicación de iPhone debe una aplicación mantener las referencias a sus Clases de modelos (utilizando el enfoque MVC)?

La capa de controlador mantiene las referencias a la capa del modelo.

¿Así que la aplicación Delegate a controller? una clase modelo? ninguno de los dos?

El delegado de la aplicación es un controlador.

¿Dónde guardarían las referencias a A y B?

A y B son clases de modelo que generalmente serían creadas y propiedad de la capa de controlador.

Me gustaría saber cómo usarían mvc para armar esta aplicación que solo usa una Vista.

El propósito de la capa del controlador es permitir que el modelo y las capas sean independientes. El modelo no debería saber nada sobre el controlador o ver capas. La vista no debería saber nada sobre el controlador o las capas del modelo. El trabajo del controlador es ser un adaptador de dos extremos para el modelo en un lado y la vista en el otro.

me habría configurar su aplicación ejemplo como este:

  • delegados UIApplication a AppDelegate.
  • si el funcionamiento del servidor de clase (A) es simple:
    • AppDelegate crea y posee instancia (s) de tipo servidor A.
  • si el funcionamiento del servidor de clase (A) es complicado:
    • Cree una clase de controlador dedicada (C) para controlar el servidor.
    • AppDelegate crea y posee instancia (s) de clase C. Una instancia de (C) para cada instancia de (A).
    • Cada instancia de la clase C y posee crea una instancia de la clase A.
  • AppDelegate crea y posee una instancia de la clase ViewController, que carga y posee su punto de vista.

No está claro en la pregunta cuál es el propósito de la clase B.

  • Si se trata de un fragmento de datos que es para el uso de una única (como datos de configuración o datos de sitios web estáticos), me habría que ser creada y administrada por el servidor (A).
  • Si se trata de datos que se crea durante el funcionamiento del servidor y necesita ser visualizado en la vista, entonces es probable que desee algo como:
    • Una matriz mutable propiedad de A, para mantener las instancias de B.
    • Otra clase de controlador (D) para hacer referencia a esa matriz y actuar como un origen de datos/delegado a su vista.
3

En mis aplicaciones que suelo cambiar el nombre de la clase AppDelegate a AppController, si eso ayuda a explicar mejor las cosas conceptualmente. Su controlador de aplicación es responsable de crear y/o configurar el controlador modelo (que gestiona su colección de objetos modelo) y controlar ventanas o vistas, establecer referencias entre ellos si es necesario y llamar a los métodos en estos controladores en respuesta a los métodos delegados NSApplication o métodos de acción de alto nivel desde el menú principal. Dependiendo de cuán compleja sea su aplicación, es posible que también tenga controladores adicionales de modelo o vista que se creen fuera de su controlador de aplicación.

Por supuesto, si tiene una aplicación simple, no hay una razón real para que su controlador de aplicaciones no juegue el papel del controlador de modelo si lo desea. Lo que desea evitar es un archivo con cientos de líneas de código, todas ellas haciendo tareas conceptualmente no relacionadas.

0

En la mayoría de los casos, AppDelegate proporciona un buen lugar para colocar algunas funciones básicas (como una imagen de fondo que desee aplicar en cada controlador), pero querrá tener controladores adicionales y código de modelo en otro lugar. Un NavController o un RootController a menudo se ubicarían como una propiedad en su AppDelegate.

Entonces, yo diría que está en algún lugar entre "ninguno" y "controlador", pero se inclina más hacia "ninguno". Definitivamente no es "modelo"!

Cuestiones relacionadas