Зачем использовать UseCases?Android Jetpack не упоминает случаи использования в документах

Question

Действительно ли необходимо использовать UseCases в моем Android Clean Architecture?

В документации Android Jetpack они не упоминаются.Они получают доступ к хранилищу напрямую из ViewModels.

Разве это не лучший вариант?Разве код UseCase не только не усложняет настройку кода?

Answer 1

Если вы хотите строго следовать чистой архитектуре дяди Боба, вам следует использовать UseCases.

Они получают доступ к хранилищу напрямую из ViewModels.Разве это не лучший вариант?

Это во многом зависит от того, насколько чистая архитектура делает тестирование очень простым, а также заставляет вас думать более архитектурно, прежде чем что-то реализовывать, и не дает идти на компромиссы, что-то вроде корректирующий код , и он следует твердым принципам SOLID, которые просто великолепны.

С другой стороны, гораздо сложнее настроить проект, и иногда кажется, что вы переусердствуете над ним

Нопосле его настройки вы увидите улучшение в удобстве обслуживания и масштабируемости.

Я думаю, что здорово знать, что такое чистая архитектура и принимать то, что соответствует вашим потребностям.

Это отличный ресурс, если вы хотите узнать больше о чистой архитектуре https://caster.io/courses/android-clean-architecture и о том, как она подходит для Android.

Answer 2

Ну, я думаю, что действительно нет необходимости использовать UseCases, особенно если вы не знакомы с ними. UseCases - это просто архитектурный шаблон для создания более масштабируемого проекта и повторного использования кода.

Я лично использую UseCases, где я вижу, что это имеет смысл. Например, в нашем проекте у нас есть View, ViewModel и Repository. Два общих случая использования UseCase были бы, если

1) Два ViewModel имеют общую логику обработки данных из Repository. Это может войти в UseCase (но не обязательно, вы можете создать меньший VM только для этого)

2) Вы хотите включить плюсовый слой между Repository и ViewModel, потому что вам нужен этот слой для обработки некоторой дополнительной логики, которая выходит за рамки Repository и / или ViewModel. Например, ни Repository, ни ViewModel не должны решать проблемы планирования. (Такая проблема, как, если у вас есть кеш, получить данные на MainThread , если не переключиться на фоновый поток.) ​​

Итак, в заключение, ничего связанного с архитектурой не нужно. Вы не должны навязывать что-то своему проекту, архитектурные шаблоны существуют только для того, чтобы ваше приложение было легче модифицировать, масштабировать, работать с ним.