CODEWITHSUNDEEP
androidmodel-view-controllermvvmmvp
N Sharma
N Sharma

Reputation: 34507

Drawback of MVP over MVVM design pattern in android

Hi I am reading this post https://news.realm.io/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/ where they explained very well about mvc, mvp, mvvm. I undertood how mvp design pattern works.

I don't find any drawback in MVP over MVVM. As they suggested this is issue

Presenter Concerns -> Maintenance - Presenters, just like Controllers, are prone to collecting additional business logic, sprinkled in, over time. At some point, developers often find themselves with large unwieldy presenters that are difficult to break apart.

Can anyone explain what does it means with an example & how it can be resolved using MVVM ?

Upvotes: 9

Views: 3724

Answers (2)

Quang Nguyen
Quang Nguyen

Reputation: 2660

As in the MVVP introduction in the article said:

MVVM with Data Binding on Android has the benefits of easier testing and modularity, while also reducing the amount of glue code that we have to write to connect the view + model.

Main differences of MVP and MVVP are:

  • View layer: In MVP, your View is totally a dumb and passive View. But in MVVP, your View is more flexible because it can bind to observable.
  • In MVP, your Presenter takes care almost everything because of dumb View, so it will become really big and complicated gradually. Meanwhile, in MVVP, ViewModel have support from View (its a little bit smart :D), especially Data Binding, you can reduce a part of logic codes.
  • Therefore, you will write a lot of codes for Presenter and they are logically related in which you will find it difficult to break down.

However, many developers prefer MVP because they do not want some business logic codes being part of XML layout.

Upvotes: 5

Jahnold
Jahnold

Reputation: 7683

I'm a big advocate of MVP and haven't really tried MVVM. The drawback of the possibility of a Presenter getting out of control is something I've had experience with but it can be mitigated.

In the example from the post the business logic will be relatively simple. There is likely only one model to deal with and not too much complex logic.

Let's think of a more complicated example though. Say you have an app that sells flowers. Once the user has chosen their bunch of flowers they get taken to the order options screen where they can:

  • add a message to the flowers
  • choose a gift vase
  • select postage addresses
  • choose a delivery date

Then add some domain requirements:

  • you can't add a message if they're delivering abroad
  • some areas have different lead times on delivery
  • some vases are only available with some flowers

This might not be the best UX but putting that aside you now have a Presenter that has to deal with many different Models (account, address, vases, orders) and can very quickly start taking on many responsibilities beyond simply telling the View what to display and passing events to the Model. This violates the Single Responsibility Principle. Also any time a class starts getting beyond 500 lines I start getting upset.

The solution is relatively simple though. You separate all your separate bits of logic out into UseCase classes. I use a relatively simple base class as follows:

public abstract class UseCase<I, O> {

    public static final int NO_STATUS = -1;

    public Observable<Integer> getStatus() {
        return Observable.just(NO_STATUS);
    }

    public abstract Observable<O> getAction(I input);
}

You specify an input & output type and inject all the models you need in the constructor in the concrete implementation class. The Presenter takes events and input from the View passes this to the appropriate UseCase, this then does the complex logic with the Model and returns the appropriate data to the Presenter to update the View.

You can send periodic status updates back to your Presenter using the status if needed to update the UI state.

This way your Presenter returns to being a simple conduit for transferring data & events between the View and the Model and the business logic is nicely contained in a separate class for each action.

Upvotes: 11

Related Questions