Home Analysis and system design Why VIPER is a good choice for your next application

Why VIPER is a good choice for your next application

by admin

When I read the article where the author said that the VIPER architecture is full of problems, it made me feel a bit negative and I immediately decided to write an article to support the architecture.

Introduction

VIPER, like modern bloggers, has gathered quite a lot of hype around itself. She has developed both her haters and people who are pious believers in the perfection of this architecture. VIPER’s haters have generated a lot of misconceptions of various kinds. Here are some of them :

  • There are too many classes in the VIPER module
  • High entry threshold – inexperienced programmers cannot work with it
  • No standardized solution for a lot of problems
  • Presenter is an unnecessary component that deals solely with mediation
  • Why do I need the 99% code test coverage that VIPER provides?

I can’t boast a large number of projects I’ve written using VIPER, but there they are nonetheless. And based on my experience, I can say that there are quite logical answers to all these misconceptions.

About a large number of classes

Let’s start by saying that there are a lot of classes and protocols in the architecture for a reason. It’s necessary for weak cohesion and high meshing, which together make the code understandable, easy to maintain, reusable, and resistant to external changes. This makes it easier to work on a project, whether it’s team development or not. VIPER, by following these principles, makes it easy to change parts of the module, thus providing a quick response to changes in design or requirements.

About the threshold of entry

Now about the threshold of entry. It’s really "big", but only for a beginner. Not to hide it – I did not immediately figured out how to write the VIPER module myself, but I also had only a few months of development experience at that time. And when we in our company decided to use VIPER for the first time, my colleagues needed only one code review of a ready module to write their own. So the architecture is not complicated at all, it is hard to make myself understand it.

About standards

At first glance, everything about VIPER seems clear – View displays, Interactor provides, Router transitions, and Presenter binds. But that’s just the tip of the iceberg. When you start writing the first module, you often can’t figure out where to write certain code. And many programmers rely on other people’s solutions, which can solve the same problem in different ways. And programmers start talking about how VIPER is bad. It seems to me that it’s not about VIPER, it’s about the very examples that people look at. What is the probability that a person understood the architecture well before posting his code? The same as the probability of meeting a dinosaur in the street – 50%. So first of all you have to think with your head and then everything will fall into place. In fact, in VIPER the responsibilities between the components of the module are very clearly divided. And if you don’t know where to put something, just read VIPER again or watch book RamblerCo.

Presenter

There’s an opinion that Presenter is an intermediary between View and Interactor and that this component is unnecessary in VIPER module. I’ll say probably the most obvious things, but still. First, Presenter stores the state of the whole module. Second, the Presenter acts as the Input and Output of the module. Third, it doesn’t just pass commands from View to Interactor, etc., it makes decisions about what to do, and that’s not exactly mediation.

About testing

And the last question – why do we need the 99% code coverage that VIPER provides? At first glance the answer is right on the surface, that’s why we need to make sure the application works correctly. But this is most likely not about the number, it’s about the fact that VIPER allows us to do this. And it allows to do so quite easily, in contrast to some other architectures. And this is a huge plus when you develop projects of any complexity.

Conclusion

Yes, VIPER has its flaws (nothing is perfect), but you shouldn’t neglect it. But you shouldn’t use it in every project in a row either. Application architecture is chosen based on many different factors and requirements, not just because of fanaticism. And before saying it’s good or bad, you should write 2 or 3 applications using it, to weigh it all up properly.
I hope I haven’t exceeded the word VIPER per square centimeter.
Thanks for reading!

You may also like