ios - color - ¿Deberían las vistas tener referencias modelo?

toolbar ionic color

Question

Digamos que tenemos las siguientes clases:

Ver

@interface ArticleView : UIView
@property IBOutlet UILabel *titleLabel;
@property IBOutlet UILabel *bodyLabel;
@end

Modelo

@interface Article : NSObject
@property NSString *title;
@property NSString *body;
@end

Controlador

@interface ArticleViewController : UIViewController
@property Article *myArticle;
@property ArticleView *myArticleView;
- (void)displayArticle;
@end

@implementation
- (void)displayArticle {
    // OPTION 1
    myArticleView.titleLabel.text = myArticle.title;
    myArticleView.bodyLabel.text = myArticle.body;    

    // ... or ...

    // OPTION 2
    myArticleView.article = myArticle;
}
@end

OPCIÓN 1

• PRO: Tanto la vista como el modelo no están acoplados entre sí.
• CON: El controlador necesita conocer los detalles tanto del modelo como de la vista.

OPCION 2

• PRO: El código del controlador es ligero y flexible (si la vista o el modelo cambian, el código del controlador permanece igual).
• CON: La vista y el modelo están acoplados y, por lo tanto, son menos reutilizables.

En la OPCIÓN 2, ArticleView tendrá que cambiarse para mantener una referencia al modelo:

@interface ArticleView : UIView
@property IBOutlet UILabel *titleLabel;
@property IBOutlet UILabel *bodyLabel;
@property Article *article;
@end

A continuación, se puede sobrescribir el conjunto de artículos para actualizar la vista de la siguiente manera:

- (void)setArticle:(Article *)newArticle {
    _article = newArticle;
    self.titleLabel.text = _article.title;
    self.bodyLabel.text = _article.body;
}

Entonces mi pregunta es, ¿cuál de estas dos opciones es la mejor en términos de OO y las mejores prácticas de iOS / MVC?

Ciertamente los he visto usar a ambos. He visto la OPCIÓN 2 usada comúnmente en las subclases de UITableViewCell.

También he leído que las vistas y los modelos deben diseñarse para ser reutilizables y no depender de nada, mientras que los controladores de vista están destinados a ser los menos reutilizables del grupo.

Mi intuición es usar la OPCIÓN 1 simplemente porque prefiero que el controlador de vista haga el trabajo sucio de vincular el modelo a la vista y dejar que el modelo y la vista permanezcan independientes y sin darse cuenta el uno del otro. Pero como algunos puntos de vista están diseñados para hacer una sola cosa, quizás no sea tan malo vincularlos directamente a un modelo específico.

Me encantaría escuchar tus opiniones sobre esto.

Answer 1

Como otros han dicho, la Opción 1 es el enfoque más puro. El controlador debe ser una "caja de conexiones" entre la vista y el modelo.

Sin embargo, varias implementaciones de este tipo de enfoque (por ejemplo, el marco al que Microsoft llama MVC) rellenan la Opción 2. Ciertamente, en el caso de Microsoft, el hecho de que la Vista y el Modelo se conozcan permite al IDE crear muchos códigos repetitivos. , y le ahorrará el "problema". La ventaja de esto es que te dedicas a escribir código de "función" en lugar de código de "cableado". Entonces, puro o no, puedes apreciar de dónde vienen.

Como suele suceder en el desarrollo de software, la elección entre la Opción 1 y la Opción 2 se reduce a la pureza frente al pragmatismo.

Answer 2

En términos de la orientación oficial de Apple sobre este tema, el MVC como una sección de Patrón de diseño compuesto del documento Conceptos en Objective-C Programming aborda ambos enfoques, pero articula claramente la preferencia de Apple de su opción 1 sobre su opción 2. De hecho, el Cocoa Core Competencies solo enumera la opción 1.

Nunca me he arrepentido de haber implementado el enfoque de la opción 1, pero cuando corté las esquinas e intenté que los modelos y las vistas interactuaran directamente, a menudo me arrepentí cuando tuve que volver atrás y modificar un sistema en una fecha posterior.

Answer 3

Francamente, a veces hago la Opción 2 yo mismo. Pero la Opción 1 está ''fuera del libro''.

Answer 4

La opción 1 es MVC. La opción 2 no es.

OO está realmente en un nivel diferente, tiene objetos para el Modelo, la Vista y el Controlador, por lo que no puede hacer mucho más para ser OO.

Ambas opciones, por supuesto, funcionarán, pero MVC existe por una razón (estoy seguro de que ya has hecho una lectura general como esta ) y encontrarás que tu código es más fácil de leer, comprender y reutilizar si sigues los principios. de MVC.

Answer 5

No siempre es una decisión de ambos. Su primera opción es más típica de la versión de MVC de Apple; En general, es cierto en iOS que el modelo y la vista no se comunican entre sí directamente, y el controlador hace la mayor parte de la coordinación entre ellos. Sin embargo, no es irrazonable tener una vista personalizada que sepa sobre clases específicas dentro del modelo más grande. Es muy posible que tenga un ArticleView que sepa qué hacer con un artículo, pero ArticleView debería recibir cualquier artículo que muestre desde el controlador en lugar de obtenerlo directamente del modelo más grande.

Uno de los objetivos de MVC es hacer que las clases de modelo y vista sean más reutilizables. Si mantiene su ArticleView muy simple, para que el controlador tenga que hacer todo el trabajo de interpretación de un artículo, entonces puede estar perdiendo reusabilidad: cada vez que quiera reutilizar ArticleView con un nuevo controlador de vista, debe reproducir todo el código que interpreta el artículo para ArticleView. Alternativamente, siempre usa la misma clase de controlador de vista para administrar un ArticleView. Ninguno de estos es realmente "reutilizable".

Al mismo tiempo, debe reconocer que existe un acoplamiento natural entre Article y ArticleView simplemente en virtud del hecho de que ArticleView está diseñado para mostrar todos los detalles relevantes de un Artículo, ya sea que los obtenga directamente del Artículo o los tenga configurados. por el controlador de vista. Si el artículo cambia, hay una gran probabilidad de que ArticleView tenga que cambiar, ya sea que sepa sobre el artículo o no.

Entonces, aunque el artículo puede ser una clase modelo, puede estar bien tener una vista que lo sepa. Lo que no quiere es un ArticleView que sepa sobre el modelo más grande e intente buscar artículos del modelo en sí. Eso limita los artículos que puede mostrar en ArticleView a solo aquellos que se pueden encontrar donde se ve ArticleView: le impide mostrar artículos de otras fuentes.

Answer 6

Sí, has demostrado comprensión del tema.

La OPCIÓN 1 es la estructura clásica de MVC, y la recomiendo como la ruta predeterminada de los dos presentados.

El hecho de que la OPCIÓN 1 sea una definición más pura, no significa que deba aplicarse en todas partes.

La desviación más frecuente que realizo es cuando una implementación es tan específica y no se reutiliza que introducir un tipo de controlador dedicado solo da como resultado más código para escribir y mantener cuando las implementaciones son pequeñas, muy especializadas, no reutilizables, y no crecerán sustancialmente. Si el programa se presta bien para plegar el V y el C en una sola implementación y cabe en algo pequeño (por ejemplo, decenas de líneas de código), no me preocupo por usar la OPCIÓN 2.

La realidad es más complicada que eso, pero la esencia es: no te sientas obligado a cumplir el n. ° 1, aunque probablemente no entiendas cómo usar el n. ° 2 puede introducir problemas de mantenimiento hasta que hayas escrito y mantenido algunos programas de tamaño moderado durante algunos años. Pasar de uno a otro puede introducir muchos cambios en un programa enviado, lo que podría haberse evitado.

El uso de la OPCIÓN 2 debe ser la minoría. En caso de duda, use la OPCIÓN 1.

De cualquier manera, creo que el modelo no debe saber sobre la vista o el controlador.

Para mí, la adhesión estricta es más importante cuando se escriben componentes reutilizables .