MVP в Android. Часть 1

MVP_2-en

Архитектурные шаблоны являются важнейшей частью ПО. Они помогают сохранить код в чистоте, сделать его расширяемым и тестируемым. Шаблоны постоянно меняются и в Android на смену Model View Controller приходит Model View Presenter.

В первой части этой статьи мы обсудим основные различия между MVC (Model View Controller) и MVP (Model View Presenter), почему в MVC уступает MVP и какие у второй модели есть преимущества.




Android SDK

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

Однако Android позволяет применять нам другие типы архитектур. Хотя MVC довольно распространенное и надежное решение, все же оно сдает позиции своему младшему брату MVP, который более четко разделяет зоны ответственности компонентов приложения.

Что мне использовать: MVP или MVC?

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

 

MVC-vs-MVP

Разница между MVP и MVC

Вот основные отличия (или даже преимущества) MVP модели от MVC:

  • View сильнее отделена от модели, а Presenter является посредниками между ними
  • Легче писать unit-тесты
  • Как правило, для каждого View существует свой Presenter

А вот особенности MVC:

  • Controller может взаимодействовать с несколькими View
  • View может напрямую общаться с моделью




Model View Presenter (MVP) в Android

Android не определяет зоны ответственности между компонентами приложения, поэтому вся логика работы с UI и данными приложения описана внутри одной Activity, что не позволяет сделать приложение расширяемым и легко тестируемым. Использование MVP позволяет решить эту проблему.

MVP_2-en

Лучший способ реализации шаблона MVP

Есть много интересных подходов для реализации MVP, но не зависимо от выбранного решения должны сохранятся три компонента:




Presenter

Presenter выступает в качестве посредника между View и Model. Он извлекает данные из модели и передает их во View. Но в отличие от типичного MVC, он также решает, что нужно делать, когда вы взаимодействуете с View.

View

View, как правило, реализуется в Activity, которая содержит ссылку на презентер. Единственное, что делает View, это вызывает методы презентера при каком-либо действии пользователя

Model

Model рассматривается в качестве поставщика данных, которые будут отображаться во View.

 

В следующей статье этой серии, мы реализуем шаблон Model-View-Presenter в Android.

Источник: MVP in Android

Комментарии:

7 comments

  1. Артем Reply

    Определение view не правильное у вас. View не должна содержать ссылку на презентер, и не должна дергать методы презентера

      • Артем Reply

        View в MVP не должен содержать реализации, тоесть это есть interface
        interface NoteView {
        void showNote(Note note);
        }

        public class NotePresenter {

        private NoteView noteView;
        private NoteModel noteModel;

        public NotePresenter (NoteView noteView, NoteModel noteModel) {
        this.noteView = noteVIew;
        this.noteModel = noteModel ;
        }

        public void loadNote() {
        Note note = noteModel.getNote();
        if(note != null) {
        noteView.showNote(note);
        }
        }
        }

        NoteActivity extends Activity implements NoteView {

        @Override
        protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        NoteModel noteModel = new ….
        NotePresenter notePresenter = new NotePresenter(thid, noteModel);
        notePresenter.loadNote();
        }

        @Override
        public void showNote(Note note) {
        textViewName.setText(note.getName());
        textViewDescription.setText(note.getDescription());
        }
        }

        Это простая реализация, тут опущены проверки, подписки. отписки и т.д.. Model — это данные (из ести, из БД, из карты памяти и т.д.), View — просто отображает данные, НЕ КАКИХ ССЫЛОК на презентер не содержит, Presenter как вы парвилньо написали дергает методы модели и передает во вью + в презентере должна хранится вся бизнес логика.

    • gc986 Reply

      Если рассматривать активность как View, то он определённо будет содержать ссылку на презентер (посредник), так как приложение завязано на жизненном цикле активности, в особенности начальной. Можно конечно хранить презентер в сервисе и общаться с активностью по средствам широковещательных сообщений, но зачем?

  2. иван Reply

    без кода на java эти все рассуждения кажутся лишенными скелета

    • Admin Post authorReply

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *