Clean-Arch-Schichten für Cars: - lib/domain/entity/car.dart: UUID-id, accountId (Personalnummer), plate, active. Pendant zum Backend-Schema. - lib/domain/repository/cars_repository.dart: Port — listMine, create, update. Keine teamId/personalnummer-Parameter, der Account fließt serverseitig aus dem JWT. - lib/data/mapper/car_mapper.dart: API-DTO (built_value) → Domain. - lib/data/repository/cars_repository_impl.dart: konkrete Impl via generierter CarsApi (dio), mit DioException → CarsRepositoryException- Übersetzung. Feature-Cars-Refactoring: - CarsBloc nimmt jetzt die Domain-Repository-Schnittstelle. Events: CarLoad/CarAdd/CarEdit/CarDeactivate (statt CarDelete). Keine teamId-Parameter mehr. Kein authBloc-Bezug, Session-Expiry läuft über den globalen Provider-Stream. - CarsState sealed mit CarsInitial/Loading/LoadingFailed/Loaded. - Pages: car_management_page, car_management, car_card, car_fail_page, car_selection_page komplett auf die neue Entity und Event-Signaturen. - Alte lib/feature/cars/service/cars_service.dart und lib/feature/cars/repository/cars_repository.dart gelöscht. CarSelectBloc + Storage: - CarSelection.selectedCarId von int? auf String? umgestellt. - CarSelectionRepository persistiert die UUID jetzt als String; defensive Migration für noch vorhandene int-Werte (alte Pre-Migration-Installations) verwirft den Wert leise und erzwingt Neuauswahl. Konsequenz-Cleanup im Tour-Code (Phase-D-Vorbereitung): - Delivery.carId String? statt int?. - Tour.hasUndeliveredLoadedArticles / getFinishedDeliveries auf String carId. - _selectedCarId / int? carId / int selectedCarId in DeliveryOverview, LoadingCustomerPage/OverviewPage, Home, DeliverySelection/SortPage, DeliveryInfo/List, CustomSortDialog, SortableDeliveryList auf String umgestellt. - TourRepository ersetzt int.parse(carId)/int.tryParse-Zuweisungen direkt durch String. - lib/model/car.dart wird zum Re-Export der neuen Domain-Entity, damit Legacy-Imports während Phase-D-Übergang weiter compilieren. DI: - app.dart: CarsBloc bekommt CarsRepositoryImpl(locator<HolzleitnerApi>()) statt der alten CarsRepository(service: CarService()). Build (flutter build apk --debug) durch, flutter analyze ohne errors.
44 lines
1.6 KiB
Dart
44 lines
1.6 KiB
Dart
import 'package:hl_lieferservice/domain/entity/car.dart';
|
|
|
|
/// Port für Fahrzeug-Stammdaten des angemeldeten Fahrers.
|
|
///
|
|
/// Bewusst **kein** `personalnummer`/`teamId`-Parameter: der Account
|
|
/// wird serverseitig aus dem JWT abgeleitet, der Client muss nichts
|
|
/// mitschicken. Eine Methode, die einen Account-Filter ermöglicht,
|
|
/// ist konsequent nicht vorgesehen.
|
|
///
|
|
/// Implementierungen werfen anwendungs-spezifische Exceptions
|
|
/// (z. B. `CarsRepositoryException`) — der Aufrufer fängt sie und
|
|
/// übersetzt in UI-Zustand.
|
|
abstract interface class CarsRepository {
|
|
/// Liste der Fahrzeuge des angemeldeten Accounts.
|
|
/// `includeInactive=false` blendet deaktivierte Fahrzeuge aus
|
|
/// (Default für die App-UI).
|
|
Future<List<Car>> listMine({bool includeInactive = false});
|
|
|
|
/// Legt ein neues Fahrzeug mit dem gegebenen Kennzeichen an.
|
|
/// Wirft, wenn das Kennzeichen für den Account schon existiert.
|
|
Future<Car> create({required String plate});
|
|
|
|
/// Aktualisiert ein bestehendes Fahrzeug.
|
|
/// Beide Optional-Parameter `null` ist ein No-Op-PATCH.
|
|
/// Soft-Delete erfolgt über `update(carId: ..., active: false)`.
|
|
Future<Car> update({
|
|
required String carId,
|
|
String? plate,
|
|
bool? active,
|
|
});
|
|
}
|
|
|
|
/// Allgemeine Repository-Exception. Konkrete Implementierungen
|
|
/// können spezifischere Subtypen werfen (z. B. `CarsUnauthorized`).
|
|
class CarsRepositoryException implements Exception {
|
|
const CarsRepositoryException(this.message, [this.cause]);
|
|
|
|
final String message;
|
|
final Object? cause;
|
|
|
|
@override
|
|
String toString() => 'CarsRepositoryException: $message';
|
|
}
|