проектирования, а вы вообще про предприятие заговорили.
» А если стартовое ТЗ изначально выдвигает более продвинутые требования в целом, то не норм.
Чем именно не норм и что именно не норм? Возможно, я не понимаю вашей мысли, но: не норм разрабатывать приложение со сложным ТЗ, используя какой-либо их архитектурных паттернов проектирования?
А хрен с тобой, вечер, воскресенье, можно и потрындеть немного ) 1. Смотри, я про MV* как про шаблоны ГУИ вбросил в контексте приложения для андроида. Не знаю, зачем ты взял абстрактнее и вбросил пример применения принципа MVC для какого-то бота без ГУИ, но это явно выходит за контекст даже самого чата, согласен? ) 2. Видимо я тебя немного не так понял, но выразился вот в каком ключе: Если приложение в началае своего развития было простым (использовано только MV*), и в процессе рефакторинга в нем формируется архитектура, то все норм. А если ТЗ изначально предполагает более продвинутую логику в Model с набором состояний да еще и набором скоупов, то пытаться все это жестко запихать в MV* (+ Rx как попсовый вариант =), устроив в Model помойку - это надежный способ стрельнуть себе в ногу. Я похожий проект недавно видел, типа "архитектура MVVM + Rx + даггер". Натурально: отдельно классы ViewModel в своем пакете, отдельно классы Repository в своем, и отдельно пакет Model, в который свалено все без разбору - работа с сетью, с преференсами, бизнес-сущности, какие-то утилиты. Интерфейсов даже между слоями нету, контекст протянут аж в репозитории и еще куча всего. Зато все типа "по феньшую" )
Обсуждают сегодня