MVP与MVVM技术问询：Presenter与ViewModel差异及视图更新

Hey there, these are really common (and important) questions when navigating MVP vs. MVVM—let’s unpack them step by step.

Let’s break this down per pattern:

• MVP: In the classic MVP setup, the Presenter takes charge of pushing data to the View. The Presenter holds a reference to the View (usually via an interface to keep things testable), and when data from the Model is ready or a UI event triggers an update, it directly calls methods on the View to set display data. For example:

  // Presenter code
  fun onUserLoaded(user: User) {
      view?.showUserName(user.name)
      view?.showUserEmail(user.email)
  }
  

  While the View could technically pull data from the Presenter, that’s not the standard approach—MVP is designed for the Presenter to drive the View’s updates.

• MVVM: This shifts to a data-driven model. The ViewModel exposes observable data streams (like LiveData in Android, or Observables in RxJava) that the View subscribes to. When the ViewModel updates its data, the data binding framework automatically pushes those changes to the View—no direct method calls needed. The View doesn’t hold a reference to the ViewModel (and vice versa, in ideal cases); it just reacts to data changes. For example, with Android Data Binding:

  <!-- View layout -->
  <TextView
      android:text="@{viewModel.userName}" />
  

  The View might fetch initial data from the ViewModel on setup, but ongoing updates are handled automatically via binding.

First, let’s cover the key distinctions:

• Coupling to the View:

  • Presenter: Has a direct reference to the View (even via an interface, it’s a tight link). This means the Presenter needs careful handling of View lifecycle events (like configuration changes) to avoid memory leaks.
  • ViewModel: Has no direct reference to the View. It only exposes data, and the View subscribes to that data. Most frameworks (like Android’s ViewModel class) handle lifecycle awareness automatically, so data survives configuration changes without extra work.

• Responsibility Scope:

  • Presenter: Acts as a middleman between Model and View. It handles UI-specific logic (like validating form input before sending it to the Model) and coordinates when to update the View.
  • ViewModel: Focuses on holding and transforming data for the View. It includes business logic related to preparing data for display, but doesn’t know anything about how the View will render that data.

• Update Mechanism:

  • Presenter: Uses explicit method calls to tell the View what to update (the "traditional method" mentioned in your question).
  • ViewModel: Relies on data binding (or observable streams) to automatically update the View when data changes.

To your second question: “MVVM uses data binding to update views, while Presenter uses traditional methods to update views”—this is mostly correct, with a small caveat. While classic MVP uses direct View method calls, some modern MVP implementations do incorporate data binding to reduce boilerplate. However, that’s not the standard MVP pattern. The core distinction holds: MVVM’s primary update mechanism is data-driven via binding, whereas MVP’s is explicit method invocation from Presenter to View.

内容的提问来源于stack exchange，提问作者user6250541