214 похожих чатов

Я так понимаю запускать foreground-сервис в юзкейсе - плохая идея,

учитывая, что слой домена не должен иметь в качестве зависимостей компоненты Android? В моем случае сервис находится в отдельном модуле от активности, и этот модуль не может иметь в качестве зависимости модуль с активити (во избежании циклических зависимостей). Запускать мне его хотелось бы по команде пользователя. Я, думаю, передавать в качестве параметра этому юзкейсу класс активности (то есть экземпляры Class<*> или KClass<*>) и стартовать сервис через метод интерфейса (назовём его Контролёром), реализация которого прописана в слое представления того же модуля, где находится этот сервис. То есть примерно та же идея, что и с репозиторием: сделать интерфейс в слое домена, а реализацию вынести в другой слой. Насколько хороший подход с точки зрения чистой архитектуры?

2 ответов

27 просмотров

В контексте чистой архитектуры и разделения ответственностей между слоями, запуск foreground-сервиса из слоя домена действительно может быть не самой лучшей практикой. Слой домена следует оставить независимым от конкретных фреймворков или компонентов Android. Ваше предложение использовать интерфейс в слое домена для запуска сервиса, а реализацию этого интерфейса поместить в слой представления, кажется более соответствующим принципам чистой архитектуры. Это позволит изолировать слой домена от зависимостей от Android и и сохранить его независимость. Вы можете создать интерфейс в слое домена, определяющий методы для запуска и управления сервисом. Затем, в слое представления, реализуйте этот интерфейс с использованием компонентов Android, таких как активность или контроллер. Это обеспечит связь между слоями, при этом сохраняя слой домена свободным от Android-зависимостей. Примерно так выглядит структура: Слой домена: kotlin Copy code interface ServiceController { fun startService() fun stopService() // Другие методы для управления сервисом } Слой представления (Android): kotlin Copy code class ServiceControllerImpl : ServiceController { override fun startService() { // Код для запуска сервиса в контексте Android } override fun stopService() { // Код для остановки сервиса в контексте Android } // Другие методы для управления сервисом } Такой подход позволяет соблюдать принципы чистой архитектуры, такие как изоляция слоя домена от фреймворков и обеспечение более гибкой и легко тестируемой системы. Однако, важно отметить, что каждый случай имеет свои особенности, и вам следует принимать во внимание конкретные требования и контекст вашего проекта при принятии решений о структуре и организации кода.

Да не как будто. А это гтпшный ответ

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Гайс, вопрос для разносторонее развитых: читаю стрим с юарта, нада выделять с него фреймы с определенной структурой, если ли чо готовое, или долбаться с ринг буффером? нада у...
Vitaly
9
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
длина пакета фиксированная, или меняется?
Okhsunrog
7
Карта сайта