notes - iphone xs plus

Propiedad del objeto modelo y MVC en Cocoa/iOS/iPhone

Question

Estoy tratando de comprender cómo implementar mejor el patrón de diseño Model-View-Controller.

¿Qué objeto debería ''poseer'' el objeto Modelo? ¿Debería un solo controlador instanciar (poseer) el objeto Modelo?

Aquí hay un escenario de ejemplo:

Tengo un UITabbarController que contiene dos UIViewControllers (controllerA y controllerB). Obviamente, ninguno de estos controladores se posee uno al otro. Tengo un objeto Modelo que contiene algunos datos y también realiza alguna actividad de red. Tanto el controlador A como el controlador B necesitan poder realizar cambios en el objeto Modelo. El controlador B necesita saber cuándo se han realizado cambios en el objeto Modelo (ya sea por el controlador A o resultados devueltos de la actividad de la red). De lectura reciente:

• Necesito KVO entre el objeto Modelo y el controlador B?
• ¿Debería el objeto Model ser un singleton? ¿Para que ambos controladores puedan modificarlo?
• En aplicaciones más simples, he tenido el control viewController del objeto Model. ¿Hay alguna forma de que un controlador pueda crear una instancia del objeto Modelo, pero que otros controladores tengan acceso de escritura a él?
• También he leído sobre el uso del delegado de la aplicación para poseer el objeto Modelo y permitir el acceso de los controladores a través de la instancia de uso compartido del delegado de la aplicación. Esto parece algo feo: usar el singleton de delegado de la aplicación para acceder globalmente a mi objeto Model. ¿No sería mejor simplemente hacer que mi objeto Model sea singleton?
• Vi a alguien en SO dar este enlace a iPhoneDevSDK, pero las razones de su método me escapan. Nuevamente, ¿no es esto involucrar al delegado de la aplicación para algo que debería ser solo un singleton?

Principalmente, ¿hay alguna otra forma para que dos Controladores accedan (escriban) a un Modelo, a menos que el Modelo sea un singleton?

Además, cuando un Controlador posee otro Controlador (por ejemplo, en un UINavigationController cuando el controlador de vista raíz ejemplifica otro controlador de vista para apilarse sobre sí mismo), ¿sería el mejor método para compartir el Modelo que el controlador de vista raíz instanciara el Modelo y pasarlo al siguiente controlador de vista antes de presionarlo en la pila de navegación)?

Answer 1

Almacenar objetos globales en AppDelegate se pone realmente feo a medida que su proyecto escala.

Pregúntese: ¿Cuál es la relación entre este modelo de objeto (s) y otros objetos en mi aplicación? Es la relación 1-a-1 o 1-a-n. Si necesita que un solo modelo sea accedido por varios objetos, entonces elija el enfoque singleton. Si necesita que un objeto tenga exactamente un modelo, guárdelo en ese objeto.

Cuando se enfrentan con alternativas de diseño diferentes, pero computacionalmente correctas, algunas áreas a considerar

1. ¿Qué enfoque minimiza las líneas de código?
2. ¿Qué enfoque causa la menor cantidad de acoplamiento y acoplamiento semántico?
3. Desde la perspectiva de un programador nuevo en el proyecto, cuyo enfoque es más fácil de entender, mantener y más difícil de introducir inadvertidamente errores.

Si comienzas a pasar modelos globales a AppDelegate, eventualmente crearás una clase monolítica que será difícil de entender y más difícil de mantener. Si crea un puntero al modelo en cada controlador, debe pasar una referencia a ese modelo cada vez que se crea una instancia de un nuevo control, y debe pasar el puntero a cualquier objeto que necesite y crear una instancia. Básicamente, has creado una cascada de pasos para pasar el mismo puntero, inflando tu archivo de interfaz y tu constructor. Imagine que, en lugar de 1 modelo, necesita realizar un seguimiento de 5 objetos modelo. ¿Tiene sentido que los objetos tengan 5 punteros para 5 modelos que deben pasarse al constructor todas y cada una de las veces? Esta es la forma de hacer que sus proyectos fallan y no se pueden mantener.

En caso de que no sea obvio. AppDelegate es solo un singleton. Cuando transfiere todos sus modelos al delegado de su aplicación, no ha evitado usar singletons, acaba de crear uno monolítico.

Con respecto a KVO: esto depende de lo que estás tratando de lograr. Daré un ejemplo de dónde es útil KVO. Supone que tiene un objeto modelo que almacena las preferencias de usuario de la aplicación.

@interface SettingsModel
.....
@property (nonatomic, retain) UIColor * backgroundColor;
@end

Otras vistas en la aplicación deberían actualizar su color de fondo inmediatamente cada vez que cambie esta configuración. Esto se puede resolver fácilmente usando KVO:

[[SettingsModel getInstance] addObserver:self forKeyPath:@"backgroundColor" options:0 context:nil];


- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
     if ([keyPath isEqualToString:@"backgroundColor"]){
         self.view.backgroundColor = [[SettingsModel getInstance] backgroundColor];
     }
}

Answer 2

El modelo puede ser referenciado por múltiples controladores. Para obtener una buena idea de los conceptos básicos del modelo-vista-controlador en el desarrollo de iPhone, consulte las dos primeras conferencias del curso de desarrollo de iPhone en Stanford (disponible de forma gratuita en iTunesU, consulte la información en Stanford en http://www.stanford.com). edu / class / cs193p / cgi-bin / drupal / ) Parece haber más formas de informar a los controladores sobre las actualizaciones de la vista y / o modelo.

No estoy seguro de por qué estás atrapado en un Singleton, y tampoco veo el problema al crear un objeto de modelo de Singleton. Creo que también debes considerar la seguridad de los hilos y las fugas de memoria.