Ответ
В архитектуре Flutter-приложения, например, при использовании Clean Architecture, Use Case (или Interactor) — это класс, который инкапсулирует одну конкретную бизнес-правило или действие. Он находится в слое домена и координирует поток данных между репозиториями (данные) и презентерами/блоками (UI).
Пример Use Case для аутентификации пользователя:
// domain/use_cases/login_user_use_case.dart
import '../repositories/auth_repository.dart';
class LoginUserUseCase {
final AuthRepository _authRepository;
LoginUserUseCase(this._authRepository);
// Выполняет конкретное бизнес-действие
Future<void> execute({required String email, required String password}) async {
// Валидация может быть здесь или в отдельном ValueObject
if (email.isEmpty || password.isEmpty) {
throw const FormatException('Email and password cannot be empty');
}
// Делегируем фактическую логику аутентификации репозиторию
await _authRepository.login(email: email, password: password);
}
}
Как это используется в слое презентации (например, с Bloc):
// presentation/login/bloc/login_bloc.dart
class LoginBloc extends Bloc<LoginEvent, LoginState> {
final LoginUserUseCase _loginUserUseCase;
LoginBloc(this._loginUserUseCase) : super(LoginInitial()) {
on<LoginButtonPressed>((event, emit) async {
emit(LoginLoading());
try {
await _loginUserUseCase.execute(
email: event.email,
password: event.password,
);
emit(LoginSuccess());
} catch (e) {
emit(LoginFailure(error: e.toString()));
}
});
}
}
Преимущества такого подхода:
- Чистое разделение ответственности: UI не знает, откуда берутся данные (сеть, локальная БД).
- Простота тестирования: Use Case можно легко протестировать, подменив
AuthRepositoryмоком. - Повторное использование: Одна бизнес-логика может быть использована в разных местах приложения (например, в мобильном и веб-интерфейсе).
- Ясность: Каждый Use Case соответствует одной пользовательской истории.