S
У каждой фичи свой репозиторий только нужных ей данных. Есть и общая репа для некоторых вещей, она в core.
А как ты понимаешь что репа должна быть в core или в фиче? в начале добавляешь в фичу, а если 2 фича попросит эту репу то переносишь в core?
Size: a a a
2020 August 27
S
Ты же не пророк и не можешь видеть будущее)
S
оч странный подход
S
Просто в своих проектах я такие вещи в core добавляю сразу
n
Singular
А как ты понимаешь что репа должна быть в core или в фиче? в начале добавляешь в фичу, а если 2 фича попросит эту репу то переносишь в core?
Пока что в core только некоторые вещи связанные с настройками всего приложения. В остальном фичи почти не пересекаются по данным. Если пересекаются только 2-3 фичи, а не почти все - то все в фичах и остается. Например данные для некоторых выпадающих списков общие для нескольких фичей, но каждая в своем модуле описывает нужный ей интерфейс репозитория который эти списки возвращает.
S
Пока что в core только некоторые вещи связанные с настройками всего приложения. В остальном фичи почти не пересекаются по данным. Если пересекаются только 2-3 фичи, а не почти все - то все в фичах и остается. Например данные для некоторых выпадающих списков общие для нескольких фичей, но каждая в своем модуле описывает нужный ей интерфейс репозитория который эти списки возвращает.
Я понял да, но в будущем может многое измениться, задачи они такие сегодня тут завтра там. Я бы на твоем месте все таки в core держал это все, на будущее. Чтобы потом не мучиться с 200 модулями и переписыванием. Просто совет.
К тому же пока что ты один пишешь
К тому же пока что ты один пишешь
n
Singular
Я понял да, но в будущем может многое измениться, задачи они такие сегодня тут завтра там. Я бы на твоем месте все таки в core держал это все, на будущее. Чтобы потом не мучиться с 200 модулями и переписыванием. Просто совет.
К тому же пока что ты один пишешь
К тому же пока что ты один пишешь
Угу. Один мегарепозиторий где в каше свалены все методы возвращающие данные? Спасибо, когда то такого уже наелся.
n
Имеет еще смысл несколько репозиториев по типам и источникам данных, а в экраны их просовывать как реализации интерфейсов репозиториев нужных только экрану, но зачем?
n
Опять же, перенести репозиторий никогда не поздно и не сложно. А вот разбираться в куче сваленных в одно место источников данных - то еще удовольствие
AD
ну так и до repository-profile-api и repository-profile-impl не долго осталось
I
Вся суть модулей в скорости инкрементальной сборки. Как иначе работать в большом проекте скажем на 2кк LOC? Я бы умер каждый собирать такое. Поэтому у нас 350+ модулей 😀
Так вроде Котлин уммет в инкрементную сборку на уровне файлов 🤔
S
Угу. Один мегарепозиторий где в каше свалены все методы возвращающие данные? Спасибо, когда то такого уже наелся.
Ну каша зависит от прямоты рук, создавайте интерфейсы, разделяйте
S
SOLID для этого и нужен же
n
Вот я это и делаю. В модулях
S
Нет, давайте плодить 500 модулей) это же так круто) завтра будете нанимать других спецов вспомните мои слова
AD
Singular
Нет, давайте плодить 500 модулей) это же так круто) завтра будете нанимать других спецов вспомните мои слова
и это я тролль, да?)
S
и это я тролль, да?)
Это сарказм, я не подддерижваю плодить много модулей, но вот ты злопамятный а))
n
ну так и до repository-profile-api и repository-profile-impl не долго осталось
Это если совсем независимые модули нужны с вероятностью переиспользования в другом приложении. Лично мне такое не нужно.
S
ну так и до repository-profile-api и repository-profile-impl не долго осталось
+
NM
Singular
Нет, давайте плодить 500 модулей) это же так круто) завтра будете нанимать других спецов вспомните мои слова
Чувак, что ты здесь вообще делаешь? Трололо жырнота? Ты задал вопрос "в чём плюсы многомодульности", тебе дали кучу ответов, а ты продолжаешь заливать что всё дерьмо, вспомните мои слова, вообще не воспринимая ответы других. Проблема не в других, проблема в тебе.