U
А как умаляются его плюсы от этого?
А там, вроде, помимо времени сборки плюсов и нету (или не было, как сейчас не знаю)
Size: a a a
2020 February 13
KD
А там, вроде, помимо времени сборки плюсов и нету (или не было, как сейчас не знаю)
Не вникая в плюсы/минусы: какие они у тебя были, такими и остаются с андроид зависимостями, но ещё и упрощается разработка
SV
А там, вроде, помимо времени сборки плюсов и нету (или не было, как сейчас не знаю)
спойлер - время сборки это не улучшает, т.к. они не смогут собираться параллельно все равно) вообще практического смысла бить на модули домен-дата-презентейшн особо нет
AY
спойлер - время сборки это не улучшает, т.к. они не смогут собираться параллельно все равно) вообще практического смысла бить на модули домен-дата-презентейшн особо нет
Разве фишка не в том, что если менял только один модуль - то остальные не пересобираются, улучшая тем самым время сборки ?
SV
Разве фишка не в том, что если менял только один модуль - то остальные не пересобираются, улучшая тем самым время сборки ?
основная фишка в том чтобы модули собирались параллельно, так что бить лучше по фиче-модулям, плюс какие-нибудь общие если надо (core и т.д.), тогда будет профит от многомодульности
SV
тут некоторые пишут делать отдельно presentation и ui, похоже на оверинжиниринг какой-то, имхо конечно же)
Kd
тут некоторые пишут делать отдельно presentation и ui, похоже на оверинжиниринг какой-то, имхо конечно же)
да, тотальная хуйня.
в отдельный модуль можно вынести апишку какую нибудь, там же и тесты накидать на нее, виджеты кастомные можно вынести отдельно (ui-kit)
в отдельный модуль можно вынести апишку какую нибудь, там же и тесты накидать на нее, виджеты кастомные можно вынести отдельно (ui-kit)
v
Имхо, понятие презентейшена ущербное и сбивает с толку, его бы заменить чем-нибудь, что будет означать не "то, что увидит юзер", а "связь со внешним по отношению к проге миром", а то так и будем сидеть и решать, в каком модуле сервисы делать. По своей сути - дата, показал из него уведомление - презентейшан, шо к чему, как быть))
v
и ещё хочется туда запихнуть вьюмодель или презентера реально, но что-то не даёт, что-то внутри говорит, что это не по-христиански)
АЕ
Имхо, понятие презентейшена ущербное и сбивает с толку, его бы заменить чем-нибудь, что будет означать не "то, что увидит юзер", а "связь со внешним по отношению к проге миром", а то так и будем сидеть и решать, в каком модуле сервисы делать. По своей сути - дата, показал из него уведомление - презентейшан, шо к чему, как быть))
То, что вы описали - это слой фреймворков. Презентейшен это частный его случай.
v
То, что вы описали - это слой фреймворков. Презентейшен это частный его случай.
всё так, но это если речь идёт о слоях, а если говорить о разграничении ответственности - начинаются проблемы чисто идеологического характера. Ну, лично у меня (и у многих, как я погляжу по комментам)
CC
А можно вопрос , что у всех такие большие проекты что нужна модульность ?
Kd
ну не два экрана
v
Constantine Cerberus
А можно вопрос , что у всех такие большие проекты что нужна модульность ?
конечно большие, ырыксов с даггерами напонапихал туда и уже большой проект)
АЕ
всё так, но это если речь идёт о слоях, а если говорить о разграничении ответственности - начинаются проблемы чисто идеологического характера. Ну, лично у меня (и у многих, как я погляжу по комментам)
Проблемы из-за того, что не понимают слои)
Kd
Constantine Cerberus
А можно вопрос , что у всех такие большие проекты что нужна модульность ?
53 экрана - большой проект? или может тут экранами нельзя считать
CC
Konstantin dmz9
ну не два экрана
Сарказм?
CC
Konstantin dmz9
53 экрана - большой проект? или может тут экранами нельзя считать
Ну экранов Мона и 100 наклипать с одной строчкой
v
Проблемы из-за того, что не понимают слои)
может быть)
Как бы вы разрешили ситуацию с сервисом?
Как бы вы разрешили ситуацию с сервисом?
v
пусть это будет ещё и фцм сервис, из которого показывают уведомления