VIPER Design Pattern – The good, the bad, but mostly good

Using VIPER for the first time, there were lots of things that I liked and very few things I didn’t like.

The Good:

A lot of the good things that come out of VIPER are primarily due to its adherence to some basic software architecture techniques. It seems to follow SOLID very well.

  • Ordered: Give some semblance of consistent order for an iOS application with very clear roles and definitions. With single object responsibility, we gain some real serious clarity of what should go where.
  • Flexible: Lends itself very well to flexible development. Need to get something in right this moment? Sure – just ham it into the ViewController and call it a day. Need to go back and refactor this? Sweet – it should be straightforward to pull something out of the ViewController and into the Presenter, Interactor, or Data Manager
  • Modular: Each VIPER chain is essentially its own module. Have a UIWebView with a bunch of custom work? Maybe it makes sense to pull it out into its own VIPER chain. Have a set of very special buttons with very specific behaviors (god forbid) – maybe it’s time to wire up another VIPER frame. Flexibility, again, pays another key role here – because you’re driven primarily from the needs of the project at any given time, you can adjust your development efforts with relatively little complicated development
  • Useful – even when you forget your need it…platforms? : Not that we should be getting in the habit of writing code we never use – we should always be very tight about what gets in there and what doesn’t – BUT, especially when we’re writing platforms, VIPER seems like it would be useful from the perspective of introducing interfaces for a library or platform – in the sense that you can write functions, and then if you never actually use them in the ViewController or the Presenter, you could just leave them there for future use. Again – another one of those benefits of single object responsibility

The Bad

  • Boilerplate : If you hate boilerplate, unfortunately there’s no real good workaround here. It’s kind of a given specifically because you’ve segregated your otherwise 10 line code in the ViewController into 25 lines found in the ViewController, Presenter, Interactor, and DataManager. Is it worth it for a small project? Probably not. But it seems to pay dividends if you expect that the requirements will just continue to grow.
  • Convention : While there’s definitely ways to make this work in a less verbose way, you are nonetheless reliant on convention to some extent. This is intrinsic to boilerplate as well, because now you have a lot more handshaking code. But because there are now more layers of obfuscation – you now need to be even more disciplined about naming and consistency. If you’re not, you can very quickly take an otherwise good pattern and have it fall apart.
  • Laziness : At the same time that it’s flexible, it’s almost so flexible that you have the opportunity to be lazy and not be heavily penalized for it. Meaning – you could still leave everything in the ViewController and Presenter and still not really do a complete fix that you need to make in the DataManager or Entity layers
  • Where do services go? : While minor, there is always the question of where do your services go. It’s apparent that you need something between your data manager and entities – something that takes care of some of the more boring retrieval aspect. So where does this happen? Does it happen in the Data Manager? Does it happen in the Entity? Does it happen in – maybe – a utility method separate from the two?

Final Verdict?

VIPER works, and as always, requires discipline – plain and simple.

It’s suitable for small to large projects – and that makes sense. It’s made with many of the concepts we read about in Coding Horrors or Uncle Bob’s book on programming. It was made specifically to address development in larger teams with multiple people working on multiple modules of a medium to large sized app.

Is it overkill for small or basic applications? Maybe. But if you’re working on a small or basic project (especially something of worth), you’ll definitely encounter requirements creep at some point. So what to do?