Intro. “SVC” the better pattern against “MVP”

Hello everyone :)

First, I’m sorry for bothering you with uncomfortable title telling you “MVP” is not good.

Actually MVP is pretty good pattern to divide into 1. business & 2. view

After I implemented a simple example with MVP. I was kinda satisfied a lot.

However

However in the company, to apply MVP in a real market product. I felt something wrong is going in here. Especially, for complicated view with many fragments and logics.

I listed down 4 reasons why “MVP” is not good enough.

1. The name of “Presenter”

One of the thing made me difficult to think was the name of “presenter”.
It cannot present anything without view. but why presenter?

It took a while to understand the presenter concept at first.
And Now I can say “Presenter” is
-> It processes business logics and reflected the result to “view”

I had to look out source codes and examples to understand “Presenter”.
I’m sure it’s because the name is not “Intuitive”.

2. Annoying making interfaces

usually when we start to make“Presenter”, “View” we declare interface first.

every single fragment, activity has 3friends “presenter”, ”presenterImpl”, ”view”

It look clear at first. However every time when I make those interface it starts to annoying me.

1. When I make a Fragment or Activity I have to make each interfaces.

2. After done interfaces making. I have to override the method.

3. Some project uses Contract class to reduce public interfaces, then when I type “View” what I see is hundreds of Contract Views interfaces like below.

Wow

4. If we recycle a “Presenter” or “View” interface more than one fragment or activity -> is Fine. However, usually 99% of screen. those interfaces exist for only one fragment or activity. (In my experience)

3. The most important thing is structure

Most of the examples in the githubs uses view implements on Activity, and Fragment. And there is “Presenter” inside the fragment or activity.

Again

“Presenter” inside the fragment or activity

Again

“Presenter” inside the “View”

This was the thing why we had a hard time with MVP

From the Presenter’s perspective. It is not seems wrong. It does what it should do.

From the View’s perspective. It has big problem.
View knows every business logics. And Even it can call it.

presenter.doLogic()

This means that view should care about logic and flow.
This means when you write code in fragment and activity (view) you should care about logic. It’s gives you a headache.

(of course I saw many good MVP projects which divided logics very well, however there are possibilities to write business logics in the View(fragment, activity), and actually the code presenter.doLogic() is business logic already)

4. Lifecycle

We should care about Fragment, Activity Lifecycle difference.
Fragment came out for replace some Activity’s region to show independent screen.
So I expected to develop fragment like activity. The reality is not so.

The Lifecycle is different. we should care about different Lifecycle.

When we use “replace” transaction “A” to “B” fragment. “A” fragment get removed then “B” added. When we pop “B” -> “A” created again so in some case we inflate view again or save view instance for cache to return.

So usually when we use MVP for Fragment, Fragment code get long with overriding “onCreate”, “onCreatedView”, “onViewCreated”.

So many things to care about.

What I want to care about is Creation and Destroy

As we saw

As we saw above. I wanted to solve the 4 reasons. And now I suggesting you a new pattern “SVC”. I wrote a basic concept in the next article below. Check it out.

Next Article

https://medium.com/@bansooknam/svc-the-better-pattern-against-mvp-66e6d342a23f