Архитектура????

Согласно википедии, архитектура программного обеспечения относится к структурам высокого уровня в программной системе, к дисциплине создания таких структур и да-да и бла-бла … мы все знаем, что такое архитектура!

Простыми словами, решив и внедряя определенную архитектуру кода или шаблон дизайна, мы все время решаем проблемы, с которыми сталкиваются разработчики.

Проблемы

Некоторые распространенные проблемы, такие как жесткая связь кода, когда даже небольшое изменение в одной части кода приводит к изменениям / ошибкам в какой-либо другой части кода.

Уменьшение повторного использования в конечном итоге приводит к копированию строк кода. Не подходит для тестирования и т.д.

Решение

Сам Android написан как MVC, где Activity отвечает за более или менее все. Для простых приложений, которые могут быть достаточно, но по мере увеличения сложности возрастает и уровень проблем.

В наши дни существует множество различных архитектурных подходов, таких как MVP, FLUX, MVI, MVVM и т.д., которые оказались плодотворными в решении вышеуказанных проблем. Можно использовать любой подход, пока код поддерживается, мы можем быстро адаптироваться к изменениям, все работает хорошо, короче — счастливая жизнь разработчика.

1_r8o2sXZKkTcB7_niDrgP6g

Конечная цель

Как я вижу большую картину, конечной целью является создание вещей таким распределенным образом, что держит связанные с Android объекты в одном месте и отделяет все остальные объекты, для которых не требуется Андроид, а затем для дальнейшего разделения не зависящих от Android частей, тем самым обеспечивая модульность кода, масштабируемость, удобство в обслуживании, удобство тестирования и так далее …

Вопрос: Почему MVVM ?

Бесконечное количество разговоров и статей об архитектуре, и мы можем согласиться с тем, что наиболее популярным и широко распространенным среди рассмотренных выше является MVP — Model — View — Presenter. Об этом много шумихи, и я даже ценю это. Его зрелый образ и в определенной степени он решает проблему, но … всегда есть, но … не полностью.

Мы можем согласиться с тем, что ничто не является совершенным, и всегда есть возможность для улучшения.

MVP зрелый, удивительный, но Google представил Android Architecture Components, который включает ViewModel, а не Presenter, и, следовательно, это доказательство того, что даже Google поддерживает MVVM.

Должно быть что-то не так с MVP !!??

Простой MVP выглядит

1_aXi4Z3sZCJhCDPjIzXD3uA

 

Читать ещё :   Использование Android Jetpack для ускорения разработки приложений

и простой MVVM выглядит

1_H52EFgiP8PgUS4BYAtMHJQ

Выше показаны очень упрощенные представления обоих. Вы можете заметить разницу??

Давайте начнем с нескольких проблем, с которыми мы по-прежнему сталкиваемся с MVP, и как мы можем использовать MVVM для их преодоления.

Тесная связь

Для каждого Activity / Fragment (View) нам нужен Presenter. Это правило с жесткой привязкой. Presenter держит ссылку на Activity и Activity держит ссылку на Presenter.

Связь 1:1, и вот где самая большая проблема.

По мере того как сложность view увеличивается, так же усложняется обслуживание и обработка этих отношений.

Для достижения нашей конечной цели «Построить вещи в распределенной манере» и избежать этих тесных связей, были введены ViewModels.

ViewModels — это простые классы, которые взаимодействуют с уровнем логики/модели и просто предоставляют состояния/данные и на самом деле понятия не имеют, кем и как эти данные будут потребляться. Только View (Activity) ссылается на ViewModel, а не наоборот, это решает проблему жесткой связи. В одном view может содержаться ссылка на несколько ViewModels.

Даже для сложных view у нас действительно могут быть разные ViewModels внутри одной иерархии.

Тестируемость

Поскольку Presenters жестко завязаны на Views, написание юнит теста становится немного сложным, так как существует зависимость от View.

ViewModels еще более дружественны к Unit Test, поскольку они просто отображают состояние и, следовательно, могут быть независимо протестированы без необходимости тестирования на то, как будут потребляться данные. Короче говоря, нет зависимости от View.

Это две основных мысли, которые сделали выбор понятным. Их может быть больше или нет. Комментарии ниже ждут этого!

Окончательный вердикт

Эти архитектурные шаблоны постоянно развиваются, и у MVVM есть все возможности, или мы можем сказать, что потенциал станет мощным, полезным, но удивительным для реализации. MVP уже развился до определенного уровня, но ничто не может быть идеальным.

Я также согласен, что есть небольшая кривая обучения, связанная с MVVM, но в конечном итоге она помогает нам преодолеть некоторые недостатки.

Не уверен в будущем, но на данный момент «One fit For all solution ~ Silver Bullet» отсутствует и одного шаблона может быть недостаточно.

Он может или не может быть похожим на MVVM, и это чисто по своему усмотрению. Пока мы можем достичь конечной цели, ничего больше не имеет значения.

PS: Это личный опыт автора, мысли и почему мы предпочли MVVM для нашего проекта. Цель здесь — не сравнивать и не обнаруживать различия. Все, что пробовал автор, — поделиться своим опытом с MVP и некоторыми недостатками, которые можно преодолеть с помощью MVVM.

Автор также подготовил образец проекта (настройка boilerplate code, ссылка), которая реализует MVVM с использованием Kotlin, архитектурных компонентов Android, RxJava, Dagger 2.

Happy Coding, Cheers!!

 

Читать ещё :   Анонс Android P для разработчиков. Часть 1

Пример приложения от Гугла: todo-mvvm-live.