MVC sin C: ¿Qué cambiará SwiftUI en la arquitectura de la aplicación?

MVC ha sido un estándar de larga data en los patrones de diseño utilizados para escribir aplicaciones iOS. La estructura de las aplicaciones de iOS que se crearon anteriormente se basó en un componente básico, que está presente en todas partes, y se llama Controlador . SwiftUI , que no tiene dicho componente, se introdujo en WWDC19 .

El problema con los llamados controladores de vista masivos debe resolverse en SwiftUI. Por lo tanto, debe encontrar una nueva forma de descomponer correctamente el código. Veamos el estado actual de la plataforma y pensemos qué paradigmas podemos usar al desarrollar para iOS13 y posteriores.

Arquitecturas unidireccionales y bidireccionales

La mayoría de las soluciones arquitectónicas que utilizan las grandes corporaciones son bidireccionales. Esto significa que puede pensar en ellas como capas una encima de la otra y que pueden comunicarse entre sí transfiriendo datos tanto hacia arriba como hacia abajo. Patrones como MVC, Model-View-ViewModel e incluso muchas implementaciones del patrón MVVM con coordinadores también son arquitecturas bidireccionales.

Un ejemplo del flujo de datos unidireccionales ampliamente utilizado actualmente en la plataforma iOS es el bucle VIP (Presentation-Interactive-Presenter) en las arquitecturas Clean Swift o Viper. Estas arquitecturas no son puramente unidireccionales. El enrutador y los ejecutables se comunican con el bucle VIP en ambas direcciones.

Otra cosa que podemos observar es que el patrón MVC y otros patrones que se construyen sobre su base están más basados ​​y ubicados en una pantalla. Por lo general, no existe una estructura clara para escribir servicios, módulos, etc., que interactúen con varias partes de la aplicación.

Flujo de datos en SwiftUI

De acuerdo con la presentación de WWDC, el elemento que conecta la vista y el modelo / estado en SwiftUI era una cierta clase de Tienda, correspondiente al protocolo BindableObject . Solo podemos esperar que no tengamos aplicaciones con una tienda masiva que contenga toda la lógica de la aplicación con todos los estados sin una estructura clara. Creo que la comunidad de iOS es bastante avanzada y puede mejorar en esta dirección.

Si ponemos MVC y SwiftUI con vista y almacenamiento uno al lado del otro, podemos ver casi la misma plantilla, lo que puede conducir a problemas similares que tuvimos con el controlador de vista, pero sin ningún código estándar que VC tiene en la naturaleza.


Si coloca MVC y almacena en un gráfico, podrían verse así.

A primera vista, Combine podría parecer el patrón arquitectónico utilizado en SwiftUI. Pero Combine es solo una herramienta para procesar valores a lo largo del tiempo. Del mismo modo, MVVM usando RxSwift sigue siendo MVVM, solo un enlace entre capas, que se implementa de varias maneras.

Arquitectura declarativa para interfaces de usuario declarativas

SwiftUI se puede resumir en pocas palabras, como una interfaz de usuario declarativa . Creo que se puede lograr más si piensa fuera de la caja y se enfoca en la palabra " declarativa ". Los ejemplos arquitectónicos declarativos más avanzados se pueden encontrar en el desarrollo de aplicaciones front-end. Conceptos como ELM, Redux y Flux se pueden usar fácilmente con SwiftUI y la infraestructura combinada. Swift ya tenía varias reimplementaciones como ReSwift , pero aún sería necesario combinar estas implementaciones en Combine .


Flujo de datos ligeramente modificado en SwiftUI desde WWDC19

Me gustaría jugar con SwiftUI desde el principio sin ninguna dependencia, y actualmente estoy experimentando en Swift con una implementación simple de la arquitectura ELM. Esta arquitectura coincide mejor con los diagramas que Apple mostró en WWDC.

Podemos describir la aplicación a través de estos patrones arquitectónicos:

• La acción es un tipo que describe todos los eventos que pueden ocurrir en una aplicación. (En una aplicación simple, esto puede ser una enumeración con algún valor asociado; en una aplicación a gran escala, puede usar muchas estructuras que corresponden al protocolo de acciones).
• Actualización (o reductor en Redux) es una función limpia simple que toma el estado actual y la acción enviada y devuelve el nuevo estado modificado. (Estas características no crean efectos secundarios y se pueden combinar fácilmente).
• Estado es un tipo que describe el estado de una aplicación. (Una lista simple de tareas puede usar una matriz).

Los tres elementos son declarativos, y cada uno de ellos es una pequeña parte comprobable y reutilizable del rompecabezas, que en conjunto conforma la aplicación completa. El estado se almacena en la Tienda y se puede calcular una vista a partir de él.


Estado, acciones y actualización para una aplicación Swift simple.

Para operaciones asincrónicas, podríamos introducir algo como un objeto de middleware en Redux o Comandos en ELM.

Conclusión

Podemos usar cualquier arquitectura que conozcamos, y cuando agreguemos gradualmente SwiftUI a las aplicaciones existentes, este será un enfoque confiable y seguro. En caso de que se implemente una nueva aplicación utilizando solo SwiftUI, puede utilizar un enfoque más abierto e intentar otra cosa.

Si piensa desarrollar una aplicación usando SwiftUI en el futuro cercano, recomendaría prestar atención a algunos puntos:

• Apple no proporciona una guía detallada sobre la arquitectura de la aplicación, lo que significa que nosotros, como comunidad de programadores, tenemos muchas oportunidades para la innovación y la implementación de nuevos enfoques.
• Definitivamente veremos una escala mucho más amplia de varias bases de código, ya que se debe llenar el hueco que queda después del controlador de vista.
• Manténgase abierto y no tenga miedo de comenzar desde cero.

Mis experimentos se pueden encontrar en el área de juegos Swift (en comparación, presenta la implementación y el uso de UIKit y SwiftUI, la misma aplicación).

Próximos pasos

Hay muchas formas en que podemos aprovechar, pero estoy muy inclinado a probar finalmente un enfoque mucho más funcional para el desarrollo de aplicaciones. Entonces, puede ver algunas soluciones interesantes de la comunidad, y todavía tenemos mucho tiempo para usar SwiftUI en el trabajo diario, por lo que todavía hay tiempo para experimentar y no hay presión sobre nosotros.

Planeo escribir más sobre esta implementación de una arquitectura unidireccional y funcional. Espero que pronto pueda usar esto en algún pequeño proyecto real, para poder contarles más sobre cómo este enfoque es viable y tiene problemas de rendimiento en proyectos a gran escala.