не увидел сразу. у вас получается в data слое есть так же описание интерфейс для репозитория и там же его реализация. а зачем тогда делать описание интерфейса для use_case если он по факту зависит от интерфейса репозитория? т.е. мы в конструктор usa_case можем передать репозиторий к примеру CounterRepositoryImpl, CounterTestRepositoryImpl, CounterApiRepositoryImpl , CounterHiveRepositoryImpl и т.д. а методах usa_case уже вызывать методы переданного репозитория, как это у вас и реализовано.
а что лучше: в слое domain описывать интерфейс для use_case или для repository? не правильней ли в domain создать интерфейс repository, а в data слое уже repository_impl?
и разве use_case не должен делать что-то одно (либо получить данные, либо сохранить)?
Спасибо, отличная статья.
Интересно еще узнать как вы строите и обрабатываете формы, используя паттерн BLoC. Какие-то вспомогательные библиотеки у вас есть для этого?
Как происходит общение между контекстами? Если, к примеру, нужно получить в контексте Баннер список товаров из контекста Рекомендации?
Если фреймворк предоставляет библиотеку для работы с чем либо, как ее протягиваете в доменный слой?
какждый релиз как праздник!!!
список для чтения - идея интересная, но можно как то добавить возможность сохранять пдф файлы?
спасибо за такой развернутый ответ =). попробую на проекте использовать подобное
статья отличная, но вот до сих пор не могу понять почему используют Either? не проще отлавливать исключения в нужном месте?
не увидел сразу. у вас получается в data слое есть так же описание интерфейс для репозитория и там же его реализация. а зачем тогда делать описание интерфейса для use_case если он по факту зависит от интерфейса репозитория? т.е. мы в конструктор usa_case можем передать репозиторий к примеру CounterRepositoryImpl, CounterTestRepositoryImpl, CounterApiRepositoryImpl , CounterHiveRepositoryImpl и т.д.
а методах usa_case уже вызывать методы переданного репозитория, как это у вас и реализовано.
а что лучше: в слое domain описывать интерфейс для use_case или для repository? не правильней ли в domain создать интерфейс repository, а в data слое уже repository_impl?
и разве use_case не должен делать что-то одно (либо получить данные, либо сохранить)?
Интересно еще узнать как вы строите и обрабатываете формы, используя паттерн BLoC. Какие-то вспомогательные библиотеки у вас есть для этого?
Работа с гитом, генератор кода и работа с базой
2 — 3
3 — 1
4 — 3
5 — 4
6 — 4
7 — 3
8 — 3