Как работает надувное представление в шаблоне проектирования MVVM?

Question

Я пытаюсь изучить Android на стороне, и я проводил некоторые исследования и считаю, что паттерн MVVM - это путь, по которому я хочу идти.Я немного знаком с ним с WPF / XAML.Тем не менее, у меня есть вопрос о том, как надувается представление (активность / фрагмент).

Это мое общее понимание шаблона проектирования:

Модель находится на нижнем слое.Этот слой будет иметь бизнес-логику и сущности.Для каждого объявленного объекта таблица хранится в базе данных SQLite с использованием Room.Чтобы придерживаться инкапсуляции, все члены данных являются частными и доступны только через get() методы.

Уровень доступа к данным хранит мою базу данных и DAO для сущности.Насколько я понимаю, DAO - это объект, отвечающий за взаимодействие между моделью представления и базой данных.

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

У меня проблема с отношением View Model и View.Модель представления не имеет представления о представлении, я понимаю, но как представления завышаются?Я знаю, что это неправильно - но мой мыслительный процесс таков: если вы используете DataBinding для привязки, например, атрибута onClick к методу в ViewModel и предположим, что этот метод отвечает за отображение диалогового окна, то ViewModel обладает знаниями View, потому чтоон отвечает за создание диалога.

По сути, мой вопрос в том, как разработчик придерживается парадигмы MVVM, когда дело доходит до надувания представлений?Если ViewModel не должен нести ответственность за какие-либо взаимодействия, связанные с View, а только за раскрытие его данных, есть ли еще один слой, который мне не хватает для преодоления инфляции?

Answer 1

Что я сделал, так это обернул логику представления представления (диалог, тост, снэк-бар и т. Д.) В абстракцию, скажем Presenter (не путать с MVP Presenter).Тогда взаимодействие обрабатывается ViewModel, тогда как фактическое отображение обрабатывается представлением.

Например:

// "Presenter" class, say for a Dialog
public interface DialogPresenter {
    void showDialog();
}

// View Model
public class ViewModel {
    private final DialogPresenter mPresenter;

    public ViewModel(DialogPresenter presenter)  {
        mPresenter = presenter;
    }

    public void onButtonClick() {
        // You can use DataBinding to bind this "onButtonClick()" method to
        // the  button click, then trigger the showing of the dialog. You can
        // add any other non-view related business logic as well. So there is
        // no direct dependencies on Android view classes and this class is
        // unit-testable by mocking out the presenter dependency.
        mPresenter.showDialog();
    }
 }

// Fragment (the "View")
public View onCreateView(...) {
    // View provides an implementation of the abstraction that will actually
    // show the dialog
    mViewModel = FragmentViewModel(new DialogPresenter() {
        public void showDialog() {
            // Show dialog in this fragment
        }
    });
}

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

Другой вариант - просто подключить логику кнопки непосредственно в представлении:

// Fragment (the "View")
public View onCreateView(...) {
    // Just wire everything up here and test via UI test (Espresso)
    mBinding.button.setOnClickListener(new View.OnClickListener() {
        public void onClick() {
            // Show dialog
        }
    }
}

Компромисс в том, что это, очевидно, более просто и прямо.Вы можете легко проверить это с помощью пользовательского интерфейса.Недостатком является то, что это не будет масштабироваться, если вам нужно расширить поведение щелчка, чтобы добавить больше логики (проверка или что-то).Тогда вы начнете получать бизнес-логику в своем представлении.

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

Надеюсь, это поможет!