JF
Если они никак не связаны то пусть 2 бд.
Они связаны. В таблице словаря используется внешний ключ из таблицы языков
Size: a a a
2020 September 11
Y
Они связаны. В таблице словаря используется внешний ключ из таблицы языков
Тогда это ответ. Проще сделать один sql запрос.
JF
Тогда это ответ. Проще сделать один sql запрос.
Вопрос больше в инициализации самой бд. Она же не может создать таблицу без самой сущности "словарь". А сущность находится в модуле
NM
Вопрос больше в инициализации самой бд. Она же не может создать таблицу без самой сущности "словарь". А сущность находится в модуле
Значит нужно выносить общие для нескольких модулей сущности в отдельный модуль (допустим БД) и подключать его зависимостью в каждый из модулей
Либо инициализировать БД в апп модуле, который знает про каждый фича-модуль
Либо инициализировать БД в апп модуле, который знает про каждый фича-модуль
2020 September 13
A
Видимо все 12го так наотмечались, что сегодня весь день тишина )
2020 September 14
EK
Видимо все 12го так наотмечались, что сегодня весь день тишина )
Или просто выходные 🤷♂️
A
Или просто выходные 🤷♂️
согласен... выходные были продуктивные )
😉
Народ подскажите если клиент не авторизовался где должен происходить обрыв соединения через setsotimeout от сервера
RK
Привет, вопрос про репозиторий:
держать интерфейс для репозитория и несколько (если нужно) реализаций, а data sources делать просто классами без интерфейсов
или же интерфейс для репо не нужен, а нужны интерфейсы для data sources, чтобы подменять их, когда понадобится
или для всего нужны интерфейсы?
Помогите разобраться.
держать интерфейс для репозитория и несколько (если нужно) реализаций, а data sources делать просто классами без интерфейсов
или же интерфейс для репо не нужен, а нужны интерфейсы для data sources, чтобы подменять их, когда понадобится
или для всего нужны интерфейсы?
Помогите разобраться.
YM
Привет, вопрос про репозиторий:
держать интерфейс для репозитория и несколько (если нужно) реализаций, а data sources делать просто классами без интерфейсов
или же интерфейс для репо не нужен, а нужны интерфейсы для data sources, чтобы подменять их, когда понадобится
или для всего нужны интерфейсы?
Помогите разобраться.
держать интерфейс для репозитория и несколько (если нужно) реализаций, а data sources делать просто классами без интерфейсов
или же интерфейс для репо не нужен, а нужны интерфейсы для data sources, чтобы подменять их, когда понадобится
или для всего нужны интерфейсы?
Помогите разобраться.
Interface в Domain ну и реализация в data
YM
и все обгорнуть UseCase
RK
Interface в Domain ну и реализация в data
интерфейс для чего и реализация чего? репо или дс?
YM
YM
в нас как-то так делают
RK
в нас как-то так делают
а дс как у вас делают? просто разные реализации дс, которые использутюся в разных репо, а сами репо реализуют общий интерфейс, так?
YM
а DS прямо в проекте еть 2 реализаци
одни ребята имеют интерфейс для DS, другие пихают все подряд в repo
одни ребята имеют интерфейс для DS, другие пихают все подряд в repo
RK
а DS прямо в проекте еть 2 реализаци
одни ребята имеют интерфейс для DS, другие пихают все подряд в repo
одни ребята имеют интерфейс для DS, другие пихают все подряд в repo
ясно, спасибо. а зачем нужна прослойка в виде use cases? почему не работать с репозиториями прямо из viewmodel, например? или это как то помогает в тестировании?
YM
вообще UseCase - это отображение того, что приложение должно делать, а Repo это просто работа с данными
конечно никто не заставляет следовать нашей дорогой и все, что делается с ViewModel - делать через UseCase, но как по мне - это очень неплохая возможность разделить логику
конечно никто не заставляет следовать нашей дорогой и все, что делается с ViewModel - делать через UseCase, но как по мне - это очень неплохая возможность разделить логику
RK
ага, спасибо
JF
Добрый вечер. В проекте реализован чат через dirtyChecking (проверка каждые 15 секунд новых сообщений). Эта логика обработки должна идти в
в перспективе возможен переход на webSocket, но пока имеем то, что имеем
domain или repository слое?в перспективе возможен переход на webSocket, но пока имеем то, что имеем