Flutter Clean Architecture

Usa questa skill per decidere dove mettere i file e come strutturare nuove feature.

Struttura delle Cartelle

Il progetto è diviso in layer. Non mischiare logica di business con UI.

lib/
├── models/       # Definizioni dei dati (Classi pure Dart, JSON serialization)
├── providers/    # State management (Riverpod Controllers & Repositories)
├── services/     # Servizi esterni (API client, Database, Local Auth)
├── screens/      # Pagine intere (Scaffold)
├── widgets/      # Componenti UI riutilizzabili (Bottoni, Card, Grafici)
└── main.dart     # Entry point

Regole per Layer

1. Models

• •Classi semplici.
• •Usa json_serializable o freezed se necessario, ma mantienile snelle.
• •Devono essere indipendenti da Flutter (niente import package:flutter/...).

2. Services

• •Contengono la logica "sporca" (chiamate HTTP, accesso al disco).
• •Devono essere esposti tramite Provider per essere mockabili nei test.
• •Esempio: AuthService, DatabaseService.

3. Providers (Logic)

• •Fanno da ponte tra UI e Services.
• •Gestiscono lo stato dell'applicazione.
• •Non devono contenere riferimenti a Widget o BuildContext.

4. UI (Screens & Widgets)

• •Devono essere stupidi.
• •Si limitano a mostrare i dati forniti dai Provider e a chiamare metodi dei Controller sugli eventi utente.
• •Usa ConsumerWidget per ascoltare i cambiamenti.

Esempio Flusso Feature "Login"

1. •Model: User (in models/user.dart)
2. •Service: AuthService (in services/auth_service.dart) -> Fa la chiamata API.
3. •Provider: AuthController (in providers/auth_controller.dart) -> Chiama AuthService e gestisce lo stato (loading/success/error).
4. •Screen: LoginScreen (in screens/login_screen.dart) -> Mostra form e osserva AuthController.