Что такое mvc android

Русские Блоги

Режим архитектуры Android один: MVC

Режим архитектуры Android: MVC

Год назад, в наши дни, большинство приложений, созданных командой Android, были гораздо менее надежными и стабильными, чем мы ожидали. Мы попытались понять, почему наш код был таким плохим, и нашли двух виновников: изменчивый пользовательский интерфейс и жесткая архитектура. Это приложение было переработано четыре раза за шесть месяцев. Окончательный шаблон дизайна, кажется, MVC, но это далеко от того, что было.
Давайте рассмотрим, что такое MVC, как он используется в Android в последние годы, как добиться максимальной тестируемости, а также о некоторых его преимуществах и недостатках.

Модель MVC

Обычно логика пользовательского интерфейса более изменчива, чем бизнес-логика, поэтому внешним инженерам нужно решение, которое может разделить пользовательский интерфейс, как делает MVC.

• ModelУровень данных, отвечающий за управление бизнес-логикой и поддержку сетевых интерфейсов и интерфейсов баз данных.
• View-Просмотр слоя, визуальная модель данных.
• Controller-Логический слой, обрабатывать поведение пользователя и обновлять необходимую модель данных.

Однако это означает, что как Controller, так и View зависят от Model: Controller обновляет данные, а View получает данные. Тем не менее, для разработки настольных и внешних приложений в то время ключевым моментом было то, что Модель должна тестироваться независимо от View. Таким образом, несколько вариантов MVC родились. Наиболее известным являетсяPassive ModelпротивActive ModelВот несколько подробностей:

Passive Model

В этой модели только контроллер может управлять моделью. Контроллер модифицирует Модель на основе поведения пользователя. Когда Модель обновляется, Контроллер незамедлительно информирует Представление о необходимости внесения необходимых обновлений. На этом этапе представление будет запрашивать данные из модели.

Active Model

Когда Controller — не единственный класс, который может изменять Model, Model требуется способ уведомления View и других классов для обновления. Это достигается с помощью режима наблюдателя. Модель содержит набор объектов-наблюдателей для обработки обновлений. View реализует интерфейс наблюдателя и регистрируется в модели.

Всякий раз, когда Модель обновляется, она будет проходить через группу наблюдателей и вызывать их update метод. Реализация этого метода в представлении инициирует операцию запроса самых последних данных из модели.

MVC в Android

Когда в 2011 году Android стал становиться все более и более популярным, естественно возникли архитектурные проблемы: поскольку MVC была одной из самых популярных моделей пользовательского интерфейса в то время, разработчики попытались применить ее в Android.
Если вы будете искать в StackOverflow такие вопросы, как «как использовать MVC в Android», большинство скажет, что в Android Activity — это и View, и Controller. Оглядываясь назад, это действительно безумие. Но в то время основное внимание было уделено тестированию модели, а реализация View и Controller обычно зависела от конкретной платформы.

Как использовать MVC в Android

Сегодня на этот вопрос хорошо ответили. Activity, Fragment и View (элемент управления Android) должны использоваться в MVCV, Контроллер и Модель должны быть другими классами, и не должны наследовать и использовать какой-либо класс в Android.
Когда контроллеру необходимо уведомить представление об обновлении, проблема их связывания становится проблемой. В пассивной модели контроллер должен содержать ссылку на представление. Для достижения тестируемости самый простой способ — создать интерфейс BaseView и позволить Activity / Fragment / View наследовать его. Таким образом, контроллер может ссылаться на BaseView.

преимущество

MVC высоко поддерживает разделение интересов. Это преимущество не только улучшает тестируемость кода, но также облегчает его расширение и позволяет довольно кратко реализовывать новые функции.
Класс Model не имеет ссылок на классы Android, поэтому он удобен для модульного тестирования. Контроллер не наследует и не реализует какой-либо класс Android, только ссылку на интерфейс View. Таким образом, модульное тестирование контроллера также возможно.
Если представление следуетПринцип единой функцииЗатем они несут ответственность за обновление контроллера и отображение данных модели на основе пользовательского ввода без необходимости реализации какой-либо бизнес-логики. Таким образом, теста пользовательского интерфейса должно быть достаточно, чтобы охватить методы в представлении.

Недостатки

Вид зависит как от контроллера, так и от модели

Вид станет очень сложным из-за его зависимости от модели. Чтобы уменьшить логику в представлении, модель должна предоставить тестируемый метод для всех данных, которые должны отображаться. В модели Active Model это умножает количество классов и методов, потому что вам нужно создать наблюдателей для каждого типа данных.
Поскольку представление зависит как от контроллера, так и от модели, логические изменения в пользовательском интерфейсе могут привести к обновлению нескольких классов, что снижает гибкость.

Кто будет обрабатывать логику интерфейса?

В соответствии с шаблоном MVC Контроллер обновляет Модель, а Представление получает данные из Модели и отображает их. Но кто решит, как отобразить данные? Это модель или вид? Рассмотрим следующий пример: теперь есть пользователь, который содержит имя и фамилию. Он должен отображаться в формате «фамилия, имя» в представлении, например «Доу, Джон»
Если модель предоставляет только метаданные, код в представлении должен быть:

Это показывает, что представление отвечает за обработку логики пользовательского интерфейса. Но это делает логику пользовательского интерфейса практически непроверенной.
Другое решение состоит в том, чтобы позволить модели отображать только те данные, которые необходимо отобразить, и скрыть всю бизнес-логику из представления. Но в этом случае Модель будет содержать как бизнес-логику, так и логику пользовательского интерфейса. Хотя это также может быть проверено, Модель неявно зависит от Представления.

Вывод

На ранних этапах разработки Android шаблон MVC сбивал с толку многих разработчиков и вызывал трудности при тестировании большого количества кода.
Зависит ли представление от модели или позволяет представлению обрабатывать логику пользовательского интерфейса, это приводит к неисправимой ошибке в базе кода, если только не реорганизовано все приложение. Каковы новые цели архитектуры и почему? Пожалуйста, смотрите следующую статью.

Источник

Что такое MVC: базовые концепции и пример приложения

Объясняем, что такое паттерн MVC и как он помогает упростить разработку.

MVC — это шаблон программирования, который позволяет разделить логику приложения на три части:

• Model (модель). Получает данные от контроллера, выполняет необходимые операции и передаёт их в вид.
• View (вид или представление). Получает данные от модели и выводит их для пользователя.
• Controller (контроллер). Обрабатывает действия пользователя, проверяет полученные данные и передаёт их модели.

Может показаться, что это что-то запутанное, но на самом деле всё просто.

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

Как работает MVC

Лучше всего понять концепцию MVC можно на реальном примере — ресторане с фастфудом. В нём посетители (пользователи) подходят к кассиру (одновременно вид и контроллер), видят меню и заказывают какое-нибудь блюдо.

Кассир проверяет, всё ли в порядке с заказом, и после оплаты передаёт нужные данные повару (модель). Повар готовит заказанное блюдо, хотя понятия не имеет о том, как выглядит посетитель, оплатил ли он заказ и так далее.

Когда модель закончит свою работу, она отправит результат в вид — обратно кассиру, который, в свою очередь, отдаст готовое блюдо посетителю.

Если же говорить о приложениях, то компоненты будут следующие:

• Вид — интерфейс.
• Контроллер — обработчик событий, инициируемых пользователем (нажатие на кнопку, переход по ссылке, отправка формы).
• Модель — метод, который запускается обработчиком и выполняет все основные операции (получение записей из базы данных, проведение вычислений).

Стоит также отметить, что реализация паттерна MVC может отличаться в зависимости от задачи. Например, в веб-разработке модель и вид взаимодействуют друг с другом через контроллер (как в примере с рестораном), а в приложениях модель может сама уведомлять вид, что нужно что-то изменить.

Зачем программистам нужен MVC

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

Например, чтобы можно было переписать способ обработки данных, не меняя при этом способ их отображения. Это позволяет эффективно работать нескольким программистам — каждый занимается своим компонентом. При этом разработчику не нужно вникать в чужой код и его действия никак не повлияют на другие фрагменты приложения.

Независимым программистам MVC тоже будет полезен, потому что они смогут сосредоточиться на разработке одного компонента за раз. На курсе по С#-разработке мы учим писать тестируемые и поддерживаемые приложения, а паттерн MVC как раз упрощает эту задачу.

Практика: пишем
MVC-приложение

Чтобы лучше вникнуть в этот паттерн, стоит применить его на практике. Для этого создайте WPF-приложение и сверстайте такую форму:

Это и есть View — его видит пользователь. Тут есть кнопка, при нажатии на которую вызывается Controller:

Контроллер получает пользовательский ввод и обрабатывает данные. Он также может проверять права пользователя. Если валидация проходит успешно, данные передаются в Model:

Модель проводит с этими данными необходимые операции, а затем вызывает метод обновления вида:

Источник

Сажаем контроллеры на диету: Android

Паттерн MVС появился достаточно давно и создавался с целью разделения бизнес-логики приложения от представления. Но далеко не все программисты реализуют его правильно, из-за чего возникают «Толстые тупые уродливые контроллеры» содержащие тонны кода. В этой статье пойдет речь о правильной реализации View классов, для того чтобы уменьшить количество кода в контроллерах и оставить место чистой бизнес-логике приложения.

Все, наверное, должны знать что MVC бывает двух типов — с активной моделью и пассивной, различие которых кроется в том, что пассивная модель служит простым источником данных (как, например, DAO для базы данных), а активная модель сама обновляет состояние своих подписчиков — View. Пассивная модель является более универсальной и простой, кроме того чаще всего используется в разработке, поэтому она будет использоваться для примера в этой статье. Давайте взглянем на её схему.

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

• При использовании MVC в Android, Activity или Fragment является контроллером.
• Модель — набор классов, которые служат источником данных приложения.
• View — xml разметка и кастомные View компоненты, на подобие Button и т. д.

Если с контроллером и моделью, вроде бы, всё понятно, то со View возникают некоторые трудности, главная их причина — View, как такого, нет, никто не задумывается о создании отдельных View классов с интерфейсом, через который контроллер мог бы передавать данные для отображения. Большинство просто создаёт xml разметку и заполняет её прямо в контроллере, из-за чего код, который по идее должен содержать бизнес-логику переполняется деталями отображения, такими как цвет текста, размер шрифта, установка текста в TextView, работа с ActionBar’ом, NavigatonDrawer’ом и прочими. В результате код Activity разрастается до 1000 строк и на первый взгляд содержит какой-то мусор.

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

Наше приложение будет решать вполне распространенную задачу — загружать и отображать профайл пользователя. Начнем реализацию.

Для этого создадим модельный класс User, в котором будет храниться имя и фамилия пользователя.

И класс provider, который будет её «загружать». Этот класс создан для демонстрационных целей, в реальном проекте не следует использовать AsyncTask для загрузки данных и не стоит писать свой велосипед, который даже не учитывает жизненный цикл Activity и не обрабатывает ошибки, лучше использовать готовое решение, например, RoboSpice. Здесь этот класс нужен, по большей части, только для того, чтобы скрыть детали реализации загрузки данных в отдельном потоке.

Далее создается xml верстка, которую мы опустим и контроллер, который должен связать View и Model, и внести немного бизнес-логики в наше приложение. В виде контроллера выступает Activity, обычно он реализуется примерно так:

При открытии экрана начинается загрузка профайла, отображается progress bar, когда профайл будет загружен, progress bar скрывается и происходит наполнение экрана данными.
Как видно из этого кода — в нём перемешивается работа с представлением и бизнес-логика.
Если сейчас все выглядит не так плохо, то при развитии проекта такой код станет плохочитаемым и трудноподдерживаемым.

Давайте вспомним про ООП и добавим немного абстракции в наш код.

View берет на себя всю работу с представлением Activity. Для отображения профайла пользователя нужно просто воспользоваться методом showUser(User) и передать ему модельный объект. В реальном проекте для View желательно создать базовый класс, в который можно перенести вспомогательные методы, такие как showProgressBar(), hideProgressBar(), и другие. В результате вся логика работы с представлением вынесена из Activity в отдельную сущность, что в разы уменьшает объемы кода контроллера и создаёт прозрачную абстракцию работы с View.

Activity же теперь ничего не знает о TextView и других контролах. Все взаимодействие с представлением происходит с помощью класса UserView и его интерфейса.

Теперь контроллер оперирует всего двумя сущностями — UserView и UserProvider, в нём нет тонкостей реализации отображения данных. Код стал чище и понятней.

Сейчас класс UserView просто отображает данные, возможно вы захотите сделать сохранение состояния между поворотами экранов — этот вопрос можно легко решить создав метод, записывающий состояние View в Parcelable или Bundle. Также, скорей всего, понадобится возможность обработки нажатий, в этом случае сам OnClickListener лучше создать во View классе и в него передать Callback, который реализует ваш контроллер.

Вот, собственно, и все. Так решается проблема недооценённых View в Android. При использовании этого подхода количество кода в ваших контроллерах заметно уменьшится, уровень абстракций возрастет и доллар опять будет стоить 30 рублей.

Источник