MVCS - Tienda de controladores de vista de modelo

35

Recientemente decidí comenzar a aprender el desarrollo de iOS, y para este fin he estado leyendo Programación de iOS: la guía Big Nerd Ranch . En el libro, los autores describen un patrón de diseño MVCS - Model-View-Controller-Store , la idea básica es que, dado que muchas aplicaciones utilizan múltiples fuentes externas de datos, mantener la lógica de solicitud en el controlador puede ser muy complicado, en cambio, los autores proponga que mueva toda la lógica de solicitud fuera del controlador y dentro de un objeto separado.

En resumen para citar el libro

Model-View-Controller-Store coloca la lógica de solicitud en un objeto separado, y llamamos a este objeto una tienda (Figura 28.4). El uso de un objeto de tienda minimiza el código redundante y simplifica el código que recupera y guarda datos. Lo más importante, mueve la lógica para tratar con una fuente externa a una clase ordenada con un objetivo claro y enfocado. Esto hace que el código sea más fácil de entender, lo que facilita el mantenimiento y la depuración, así como compartirlo con otros programadores de su equipo.

Y

Lo bueno de las tiendas asíncronas es que, aunque muchos objetos están haciendo un gran trabajo para procesar una solicitud, el flujo de la solicitud y su respuesta están en un solo lugar en el controlador. Esto nos brinda el beneficio de un código que es fácil de leer y también fácil de modificar.

Quería obtener más información sobre este patrón y ver lo que otros podrían decir sobre él, pero mientras buscaba en línea, las únicas referencias que pude encontrar fueron sobre ese mismo libro (¿quizás el patrón se conoce con algún otro nombre?).

Para mí, la lógica del autor parece tener sentido, y parece una extensión lógica del patrón MVC regular, pero tal vez sea porque realmente no tengo mucha experiencia con el patrón MVC en la práctica (aparte de incursionar en el desarrollo de iOS que tengo tipo de MVV usado con backbone.js (es decir, si lo considera MVC )).

Esperaba que tal vez alguien con más experiencia pueda arrojar algo de luz sobre si hay fallas / problemas obvios con el patrón MVCS que me estoy perdiendo.

Jack
fuente
2
RobotLegs en ActionScript utiliza la "S" en MVCS para indicar el servicio. Pero se usa esencialmente de la misma manera. Así que hay al menos otro ejemplo de ello.
Amy Blankenship
1
En MVC, la tienda suele ser parte del modelo. Se llama la parte de DAO .
Florian Margaine
@FlorianMargaine está utilizando en lugar del Controlador (lo que parece estar implícito en este libro (dice "En la lógica de solicitud MVC es responsabilidad de los objetos del controlador")? ¿Y ve alguna desventaja obvia de moverlo a su propia capa? ?
Jack

Respuestas:

18

"Store", en el caso de los patrones de diseño MVCS, tiende a inclinarse hacia la lógica de almacenamiento. En el caso de iOS, esta suele ser una implementación de Core Data. Si crea una plantilla respaldada por Core Data en Xcode, verá el aspecto "Almacenar" de este patrón de diseño escondido en la clase AppDelegate.

Para llevar esto al siguiente nivel, a menudo crearé una clase de administrador singleton que se encargará de configurar la pila de Core Data y se ocupará de todas las recuperaciones / guardados relacionados con la pila. Como dice la cita que mencionó, esto hace que sea muy fácil no solo llamar a esos métodos, sino ajustarlos si es necesario, en lugar de guardar / recuperar llamadas por todas partes en diferentes controladores de vista.

Sin embargo, el paradigma de "Tienda" no está restringido a Core Data. Su tienda puede ser solo un servicio web. Quizás tenga una clase que interactúa con Facebook, Twitter, Yelp o alguna otra API basada en REST. He descubierto (y de manera similar seguir la tendencia) que este tipo de clases también se denominan Manager. Literalmente están administrando todos los detalles internos para que sus otras clases puedan simplemente poner o sacar exactamente lo que necesitan.

En cuanto a defectos o problemas obvios con este patrón de diseño ... Al igual que con cualquier patrón de diseño, el problema más evidente es garantizar que haya configurado su proyecto de tal manera que coincida con el paradigma. Especialmente con un patrón de diseño que es nuevo para usted, esto a veces puede ser la parte más difícil. El beneficio de dividir su lógica de "Tienda" en su propia clase es el hecho de que hace que el mantenimiento del código sea mucho más fácil.

jmstone
fuente
Gracias por la información, esto en realidad es similar al enfoque que comencé a tomar, ya que tengo una clase de administrador singleton que se ocupa de la pila de datos centrales y una API web.
Jack
Hola @ Jimstone, estoy un poco confundido con respecto a la lógica de la tienda. ¿Puedes por favor ayudarme? Supongamos que tengo 5 modelos, para cada uno tengo 2 clases, una que mantiene la creación de redes y otro almacenamiento en caché de objetos (datos básicos y otras cosas). Ahora debería tener una clase Store separada para cada modelo que llame a la función que contiene llamadas de función de red + caché o una sola clase Store que tenga todas las llamadas a la función de red + caché para cada modelo, de modo que el controlador siempre acceda a un solo archivo para datos.
meteoros
18

'Almacenar' en este contexto se parece mucho a un repositorio o servicio . En ese caso, este es un patrón extremadamente común. Los defectos / problemas variarán con su implementación y el dominio del problema.

A nivel general, parece que el libro está usando 'Almacenar' para representar un nivel de lógica empresarial + un nivel de lógica de recuperación de datos que maneja un conjunto de datos que pueden o no ser parte de su aplicación.

Por ejemplo, envolver la API de Twitter en una 'Tienda' es una buena manera de compartimentar esa lógica.

Después de pensarlo más detenidamente al
usar esta definición de MVC (que creo que es bastante acertada), la 'Tienda' es realmente un subconjunto del modelo. La delimitación entre si se trata de una extensión de MVC o si se trata de un patrón de recuperación de datos no es muy útil. Terminan pareciéndose al mismo código.

En pocas palabras, creo que estarás bien siguiendo los consejos que sugieren (parece ser en general).

Zachary Yates
fuente
1
Leer a través de los enlaces que proporcionó Suena similar, excepto que aquí se usa como una extensión del patrón MVC.
Jack
55
+1, parece que acaban de encontrar un nuevo nombre para el patrón de repositorio (un repositorio es un tipo de servicio).
MattDavey