¿Debo usar la arquitectura Viper para mi próxima aplicación iOS, o todavía es muy nueva?

Realmente me gusta la forma en que Khan Lou lo expresa en este artículo: Model View Whatever

“Lo mejor de la programación es que puedes hacer lo que quieras. No te dejes llevar por la ideología o la mitología “.

Ayudé a co-escribir el artículo sobre Arquitectura de aplicaciones de iOS con VIPER, e incluso dado eso, he trabajado en muchas aplicaciones de iOS que fueron diseñadas de diferentes maneras … algunas de ellas comenzaron por mí.

Lo que he encontrado es que VIPER tiende a funcionar muy bien cuando trabajas en un proyecto grande en un entorno de equipo. Crear una estructura arquitectónica consistente como esta es una excelente manera de hacer que todos trabajen en un proyecto en la misma página en términos de qué piezas van a dónde. Hace que la construcción y la reparación sean más eficientes porque todos obtienen más claridad y familiaridad con la forma en que se construye el sistema.

Si bien los proyectos de cualquier tamaño y escala pueden beneficiarse de cimientos sólidos y una buena arquitectura, esto definitivamente parece importar más para proyectos más grandes. Para una aplicación con solo unas pocas pantallas, puede permitirse usar un poco más de fuerza bruta y cinta adhesiva y aún así mantener su cordura mientras trabaja en ella. Una vez que el tamaño crece más allá de algo en el que puede ajustar toda la base del código dentro de su cabeza en todo momento, eso simplemente no va a funcionar.

Sin embargo, personalmente, tiendo a seguir los consejos de Khan en mi propio trabajo. No me gusta adherirme a ninguna metodología en todo momento, pero me inspiro considerablemente en varias metodologías, incluida VIPER.

No diría que VIPER es demasiado nuevo, porque los principios subyacentes han sido parte de la ingeniería de software durante muchos años. ¿Deberías usar VIPER? Depende de lo que pienses al respecto. Si hace las cosas más intuitivas, si crees que te ayudará a ser honesto y mejorar tu habilidad para escribir exámenes y mantener clases más pequeñas, entonces absolutamente. Pero independientemente, trate de tomar en serio algunas de las lecciones sobre el principio de responsabilidad única y similares. Incluso si no estás totalmente interesado en VIPER, todavía hay algo que puede enseñarte.

Gracias,

– Conrad

Haré mi mejor esfuerzo para darle una analogía de la diferencia entre MVC y VIPER:

MVC es como vivir en un departamento donde la cantidad de habitaciones es pequeña e igual, pero las habitaciones pueden crecer o reducirse de tamaño y no tienen puertas. Pasas la mayor parte del tiempo en casa, cocinas y duermes en una habitación, tienes un pequeño pasillo y un baño. ¿Puedes vivir en ese tipo de apartamento? Claro, muchas otras personas lo hacen.
Ventaja: todo está cerca de ti;
Desventaja: todo está cerca de ti, lo que significa que es más difícil encontrar lo que necesitas en cualquier momento.

VIPER es como vivir en un departamento con más habitaciones con puertas donde ellos también pueden cambiar su tamaño. Pero ahora, tiene una habitación separada para pasar la mayor parte de su tiempo en casa, una habitación separada para cocinar, una habitación donde duerme, un baño, un balcón, un gimnasio, etc.
Ventaja: cada habitación tiene su propósito específico y puede colocar cosas específicas en una habitación que estén en línea con el propósito de la habitación.
Desventaja: ahora su apartamento tendrá más pasillos y, si desea obtener algo, es probable que esté en otra habitación, por lo que tendrá que salir de la habitación en la que se encuentra, viajar a través de uno o más pasillos. y habitaciones hasta que llegue a la habitación que contiene lo que desea.

Entonces, las habitaciones son los componentes de la arquitectura:
MVC: Modelo, Vista y Controlador.
VIPER: Ver, Interactor, Presentador, Entidad, Enrutador.

En VIPER, cada habitación tiene una puerta, un protocolo. Eso significa que puede construir una habitación completamente nueva que se ajuste al propósito definido por la puerta y colocarla detrás de la puerta. De esa manera, puede ver más fácilmente cómo sería su vida en ese departamento sin vivir realmente en él, pruebas más fáciles.

Si le gusta la idea de vivir en un apartamento tipo VIPER, simplemente pase unos días leyendo las explicaciones y los tutoriales y eche un vistazo a los proyectos de ejemplo.

Si decide usarlo para su próximo proyecto, espere un poco de tiempo (tal vez lo retrasará unos días) hasta que haga las cosas bien. Pero, después de construir y usar un par de módulos VIPER, lo dominará y los siguientes que construirá tomarán aproximadamente el mismo tiempo que si se desarrollara con MVC.

Cuando finalmente adopte la mentalidad VIPER, la creación de módulos VIPER se convertirá en su forma más rápida de desarrollar aplicaciones iOS. Ni siquiera obtendré los beneficios de la capacidad de prueba mejorada, la opción de desarrollar utilizando el principio de desarrollo basado en pruebas y la mantenibilidad general a largo plazo, ya que probablemente ya los conozca.

He estado usando VIPER en el proyecto en el que estoy trabajando durante varios meses. El proyecto cuenta con 4 desarrolladores. La respuesta corta es: probablemente no. Probablemente.

Viper es bueno para:

• Grandes proyectos donde la principal prioridad es asegurarse de que los nuevos desarrolladores y los antiguos desarrollos sepan exactamente dónde están las cosas. Viper no es la única forma de hacer esto. Cualquier arquitectura logra eso, pero VIPER es probablemente mejor que la mayoría.
• Multiplataforma Mac / iOS donde necesita reemplazar las “vistas” (también conocido como pares de Vista / Controlador de vista) fácilmente. Esto nunca sucede, o muy raramente.
• Proyectos en constante evolución donde las cosas nuevas necesitan ser “puestas” sobre cosas viejas. Esto pasa mucho. Pero si la refactorización implica cambiar el contenido (no la forma) de las vistas existentes, entonces VIPER podría ser contraproducente.
• Donde cambian sus puntos de vista pero NO su contenido. Pero cambie el contenido y se encontrará con una mala experiencia.
• Debe tener claro en su mente cómo encapsular la lógica empresarial. Sostengo que es imposible. El término “lógica de negocios” en ingeniería no significa absolutamente nada.

VIPER tiene un gran PERO. La lógica está dispersa en un millón de archivos, tantos que, de hecho, muchos de ellos se convierten en clases de pura aprobación. Especialmente los interactores, con frecuencia no tienen lógica empresarial (¿puede definir la lógica empresarial de todos modos?), Ya que algunas vistas solo necesitan obtener información y presentarla al usuario; el usuario toca algo y se aleja. El noventa por ciento de su lógica es navegación y presentación, y debe preguntarse si la transformación de datos es lógica comercial (no lo es). Aún necesita un archivo interactor en las implementaciones más populares de viper. En tales implementaciones. cuando toca algo en la pantalla, necesita pasar la información al presentador, que debe pasar la información a un enrutador, o al interactor, que se comunicará con algún administrador de datos o servicio de datos, de regreso al interactor, nuevamente al presentador, de vuelta a la vista o al enrutador. Cada uno de estos módulos requerirá una “fachada” interna, una API si lo desea y las estructuras de datos deben traducirse de una clase a la siguiente. Cada archivo o componente VIPER tendrá que asignar sus estructuras de datos a las otras estructuras de datos en el mismo módulo VIPER (¿cómo sabría qué celda de vista de tabla se ha seleccionado?).

Entonces, “un toque, navegar a otra vista” se convierte en una cantidad ridícula de repeticiones .

Y VIPER nada en gran medida contra los marcos , corre el riesgo de perder una gran cantidad de la funcionalidad gratuita que viene naturalmente con los marcos de Apple.

Estarás reinventando constantemente la rueda o …

… Perderás las funcionalidades más complejas y hermosas por el bien del código hermoso.

(No me hagas empezar con los problemas de subprocesos ).

En última instancia, le costará mucho dinero y …

… los desarrolladores no estarán contentos, VIPER es una jaula para ellos .

En general, los principios de código limpio son un poco antiguos, especialmente cuando se consideran las características funcionales más interesantes de swift y la forma en que funcionan los marcos de iOS. Si su aplicación es tan compleja que requiere VIPER, pregúntese: ¿no debería escribir algún middleware en mi back-end para simplificar el intercambio de datos con los servidores en lugar de complicar mi aplicación?

Si realmente quiere probar VIPER, considere una implementación lite no estándar y haga que su interactor, administrador de datos, presentador y enrutador se conecte directamente con el controlador de vista y presentador, y haga que compartan una estructura de datos estandarizada. Considere deshacerse del interactor. No lo he intentado con toda honestidad, pero en algún lugar debe ser un compromiso viable.

A TODA COSTA EVITE VER MODELOS EN CONJUNCIÓN CON VIPER. Tienes un presentador para eso.

VIPER es solo una implementación de la arquitectura Clean del tío Bob.

En contraste con lo que todos piensan, la arquitectura limpia no se formuló para resolver los “grandes problemas del controlador” , este es solo uno de sus muchos beneficios. Toda su esencia es producir código MANTENIBLE:

• Agrupando código SIMPLE y EXPRESIVO, que son los CASOS DE USO de la aplicación. Esto elimina el ‘factor de bus’, cada miembro del equipo sabe qué y cómo funciona la aplicación.
  Por ejemplo, no sé qué ContactsManager hace, mejor miro su código VS. Sé que esto obtiene los contactos por nombre, ya que dice GetContactsUseCase y obtiene ContactsByNameRequestModel
• SEPARANDO entre los DETALLES y las DEMANDAS. Esta es la regla de dependencia.
  En otras palabras, al caso de uso no le importa si la fuente de datos es una base de datos, entonces, ¿por qué mezclar los dos niveles?

¡Eso es! Nada más … a menos que observe los beneficios que son:

• Código comprobable
• Codificación paralela
• Alta cohesión y bajo acoplamiento.
• Extremadamente escalable
• Más y más y más…. básicamente todo buen principio que se te ocurra

No sé qué hace VIPER, pero si te da los mismos beneficios que hacerlo.

¡Deja de codificar, comienza a diseñar!

Respuesta corta: No, no recomendaría usar VIPER.

Estaba trabajando en un proyecto que nos exigía a nosotros, 8 desarrolladores de iOS, adoptar la arquitectura VIPER. Al decir “requerido”, quiero decir que el arquitecto de soluciones de proyecto de una firma consultora convenció a las partes interesadas para que creyeran en la belleza de VIPER. Después de 5 meses de uso intensivo, creo que solo un desarrollador dijo que aún preferiría usar VIPER … para que entiendas la imagen.

El propio proyecto de muestra de VIPER es, en mi opinión, de alguna manera demasiado ideal. En realidad, si quieres practicar VIPER a fondo, debería haber más dolores. El único beneficio de usar VIPER, según lo veo, es no tener controladores de vista masivos. Sin embargo, VIPER no es la única respuesta para abordar el problema del controlador de vista gorda y seguramente no es la mejor.

Otro argumento es modularizando el código en componentes VIPER separados, luego puede reemplazar fácilmente uno de los componentes, digamos la capa presentadora, con otra implementación. Pero, muchachos, vamos, ¿con qué frecuencia se les pide que reemplace una interfaz de usuario de la APLICACIÓN con una interfaz de herramienta de línea de comandos (sí, este fue el ejemplo exacto que hizo el arquitecto de soluciones durante el inicio del proyecto, para convencernos )?

La depuración del proyecto de arquitectura VIPER también fue dolorosa, terminamos saltando de un lado a otro entre un montón de archivos fuente, y a menudo nos encontramos perdidos.

La convención de nomenclatura de los protocolos entre interactor / presentador / vista es inconsistente y engañosa. No entraría en demasiados detalles aquí, pero una vez que comience a cavar, se rascaría la cabeza de vez en cuando.

¡Ah, y terminamos escribiendo toneladas de código de prueba de unidad, porque nuestro objetivo de cobertura era del 80% y nuestra base de código de implementación se hinchó al adoptar VIPER!

En resumen, creo que VIPER es algo sobredimensionado. Honestamente, si su KPI se evalúa en función de las líneas de código que escribe, o si cobra a sus clientes por horas facturables, o simplemente no le importa el próximo desarrollador que mantendrá su proyecto basado en VIPER, continúe y use VÍBORA. Hablando por mí mismo, intentaré evitar usar VIPER en mis nuevos proyectos y buscaré otros patrones de diseño pragmáticos.

Actualización el 22 de julio de 2015

Perdón por mi despotricar anterior, nada personal. Como seguimiento, el proyecto que mencioné se realizó a tiempo con alta calidad. También escuché que los titulares de la pila de proyectos probablemente no utilizarían VIPER en sus futuros proyectos de iOS.

Si MVC es un mega monstruo que te preocupa, VIPER es una pequeña colección de monstruos que te ayuda a crear aplicaciones iOS, de una manera más agradable y controlable.
Al implementar la arquitectura VIPER, descomponemos con éxito estructuras lógicas complejas en capas de responsabilidades bien definidas. Y sí, lo hicimos en la primera fase de diseño de la arquitectura.

Ahora, finalmente podemos decir “adiós” a los Mega-ViewControllers.
Al separar las responsabilidades, también mejora el aislamiento de dependencias. Esto hace que las pruebas y la depuración sean mucho más fáciles. Dado que los archivos físicos son cada vez más pequeños y se centran más en sus responsabilidades correspondientes, facilita la colaboración en equipo.

Gerente
Apptologia

Creo que es una buena interpretación de los principios de diseño y programación del tío Bob en el mundo de iOS. Funcionaría maravillosamente bien para aplicaciones comerciales medianas y grandes. Sin embargo, podría ser una exageración para una aplicación de utilidad o algo diferente.

Sin embargo, personalmente sugeriría que te ‘inspiraras’ en lugar de seguirlo religiosamente. La primera ‘inspiración’ que debe extraerse debe ser ir a estudiar el trabajo del tío Bob, Martin Fowler, Kent Beck, etc.

Todo esto no es más que programación orientada a objetos del mundo real y no hay nada demasiado inteligente al respecto. Solidifíquese con patrones de diseño de cacao, patrones de diseño en general y pensamiento orientado a objetos, y usted mismo podría llegar a una conclusión similar.

He estado desarrollando y diseñando aplicaciones durante más de 4 años y he desarrollado arquitecturas similares. Sigo experimentando. Cada aplicación presenta nuevos desafíos. Ve lo que funciona mejor para ti.

En mi opinión, depende del tamaño y el ciclo de vida de su proyecto.
Pero para un “gran proyecto a largo plazo”, recomiendo VIPER a pesar de su complejidad. Pero puede hacerlo más simple, si está familiarizado con el Patrón de programación reactiva (RxSwift, ReactiveCocoa, …), implementando con propiedad unidireccional usando Observable en el Patrón de programación reactiva en lugar de la propiedad bidireccional que le dio el Patrón de delegado.
Si lo estás haciendo bien, creo que no es tan difícil y sigue siendo la mejor opción para un proyecto grande.
El único inconveniente de este patrón que encontré hasta ahora es una curva de aprendizaje muy alta (algunos dicen que son muchos archivos, pero creo que no es un inconveniente en absoluto). Y si incluye la programación reactiva, es aún mayor.
Pero si tu equipo puede superarlo.
Significa que su equipo se volvió más hábil y puede ver un problema muy grande con mayor claridad separándolos en pequeños módulos.
En contraste con el patrón de otros (MVC, MVVM, MVP), los inconvenientes no se pueden superar fácilmente porque son los problemas que el patrón en sí no tenía la intención de resolver desde el principio.
(Comparación de patrones Ref. https://image.slidesharecdn.com/ …)

¡Sí, usa VIPER y nunca te arrepientas!

Algunas personas dicen que puede ser una exageración para proyectos pequeños, pero puede automatizar la generación e inicialización de módulos VIPER. Por lo tanto, solo se beneficia de todos sus aspectos positivos.

Le sugiero que consulte esta publicación para obtener información detallada sobre nuestras mejores prácticas para esta impresionante arquitectura: Arquitectura VIPER: Nuestras mejores prácticas para crear una aplicación como un jefe | Laboratorios de tarta de queso

Sí, lo recomiendo totalmente. Lo apliqué en Redbooth para nuestras aplicaciones móviles e incluso desarrollé un módulo para generar módulos VIPER a partir de una plantilla: pepibumur / viper-module-generator. Aunque es una tarea pesada al principio tener que refactorizar y dividir cada componente en varios, verá que al final, proporcionará muchas ventajas a su proyecto. Código más comprobable y menos acoplado, componentes de responsabilidades únicas, …

VIPER es un poco exagerado para la mayoría de los proyectos en mi opinión. MVC no tiene que venir con controladores de vista gigantes. Sugeriría seguir el concepto detrás del VIPER en lugar de seguirlo estrictamente.

¡Tal vez! Esto tiene más información: http://www.objc.io/issue-13/viper.html