Recomendaciones y recursos de arquitectura

La separación de conceptos (separation of concerns) es el principio arquitectónico más importante. La capa de datos expone los datos de la aplicación al resto de la app, y contiene la mayor parte de la lógica de negocio de tu aplicación. La capa de UI muestra los datos de la aplicación y escucha los eventos de los usuarios. La capa de UI contiene clases separadas para la lógica de UI y los widgets.

El patrón de repositorio es un patrón de diseño de software que aísla la lógica de acceso a datos del resto de la aplicación. Crea una capa de abstracción entre la lógica de negocio de la aplicación y los mecanismos de almacenamiento de datos subyentes (bases de datos, APIs, sistemas de archivos, etc.). En la práctica, esto significa crear clases Repository y clases Service.

La separación de conceptos es el principio arquitectónico más importante. Esta separación particular hace que tu código sea mucho menos propenso a errores porque tus widgets se mantienen "simples" (dumb).

La API ChangeNotifier es parte del SDK de Flutter, y es una forma conveniente de hacer que tus widgets observen los cambios en tus ViewModels.

Hay muchas opciones para manejar el State Management, y al final la decisión se reduce a una preferencia personal. Lee sobre nuestra recomendación de ChangeNotifier o otras opciones populares.

La lógica debe estar encapsulada en métodos en el ViewModel. La única lógica que debe contener una vista es:

• Sentencias if simples para mostrar y ocultar widgets basados en una bandera o campo anulable en el ViewModel
• Lógica de animación que depende del widget para calcular
• Lógica de diseño (layout) basada en la información del dispositivo, como el tamaño de la pantalla o la orientación.
• Lógica de enrutamiento simple

Una capa de dominio solo es necesaria si tu aplicación tiene una lógica extremadamente compleja que satura tus ViewModels, o si te encuentras repitiendo lógica en tus ViewModels. En apps muy grandes, los casos de uso son útiles, pero en la mayoría de las apps añaden una sobrecarga innecesaria.

Úsalo en apps con requisitos de lógica complejos.

Las actualizaciones de datos solo deben fluir desde la capa de datos a la capa de UI. Las interacciones en la capa de UI se envían a la capa de datos, donde se procesan.

Los comandos evitan errores de renderizado en tu app y estandarizan cómo la capa de UI envía eventos a la capa de datos. Lee sobre los comandos en el caso de estudio de arquitectura.

Los datos inmutables son cruciales para garantizar que cualquier cambio necesario ocurra solo en el lugar adecuado, generalmente en la capa de datos o de dominio. Debido a que los objetos inmutables no se pueden modificar después de su creación, debes crear una nueva instancia para reflejar los cambios. Este proceso evita actualizaciones accidentales en la capa de UI y soporta un flujo de datos claro y unidireccional.

Puedes usar paquetes para ayudar a generar funcionalidades útiles en tus modelos de datos, como freezed o built_value. Estos pueden generar métodos de modelo comunes como serialización/deserialización JSON, comprobación de igualdad profunda y métodos copy. Estos paquetes de generación de código pueden añadir un tiempo de compilación significativo a tus aplicaciones si tienes muchos modelos.

Usar modelos separados añade verbosidad, pero evita la complejidad en los ViewModels y casos de uso.

Úsalo en apps grandes.

La inyección de dependencias evita que tu app tenga objetos accesibles globalmente, lo que hace que tu código sea menos propenso a errores. Recomendamos usar el paquete provider para manejar la inyección de dependencias.

Go_router es la forma preferida de escribir el 90% de las aplicaciones de Flutter. Hay algunos casos de uso específicos que go_router no resuelve, en cuyo caso puedes usar la API Flutter Navigator directamente o probar otros paquetes que se encuentran en pub.dev.

Recomendamos nombrar las clases según el componente arquitectónico que representan. Por ejemplo, es posible que tengas las siguientes clases:

• HomeViewModel
• HomeScreen
• UserRepository
• ClientApiService

Para mayor claridad, no recomendamos usar nombres que puedan confundirse con objetos del SDK de Flutter. Por ejemplo, deberías colocar tus widgets compartidos en un directorio llamado ui/core/, sino en un directorio llamado /widgets.

Las clases Repository son las fuentes de verdad para todos los datos de tu app y facilitan la comunicación con las APIs externas. Crear clases de repositorio abstractas te permite crear diferentes implementaciones, que se pueden usar para diferentes entornos de la app, como "desarrollo" y "staging".

• Escribe pruebas unitarias para cada clase de servicio, repositorio y ViewModel. Estas pruebas deben evaluar la lógica de cada método de forma individual.
• Escribe pruebas de widgets para las vistas. Probar el enrutamiento y la inyección de dependencias es particularmente importante.

A los fakes no les importa tanto el funcionamiento interno de un método determinado, sino más bien las entradas y salidas. Si tienes esto en cuenta al escribir el código de la aplicación, te verás obligado a escribir funciones y clases modulares y ligeras con entradas y salidas bien definidas.