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"
- Model:
User (in models/user.dart)
- Service:
AuthService (in services/auth_service.dart) -> Fa la chiamata API.
- Provider:
AuthController (in providers/auth_controller.dart) -> Chiama AuthService e gestisce lo stato (loading/success/error).
- Screen:
LoginScreen (in screens/login_screen.dart) -> Mostra form e osserva AuthController.
