MVC vs VIPER?? Which one to use for iPhone App Architecture?
This is an architectural debate or confusion to all developer on initial days.
Yes MVC we know as a Model, View, and Controller. Yes, this is very old approach and still holds good for most of the cases. but when the project is growing and becoming big then the number of people working also more i.e. big team size. In the big team size, we face a lot of issue with MVC. i.e according to the apple you should not do big operations on the main thread and it should be only used for UI update. So view should only know to render and it should not decide which operation to be executed next or to be called. So if you move this part to the controller then the controller will be having lot tasks which are business logic and also view update. So there is no a clear-cut separation in the task but there is no separate model in MVC all are saved in the controller so in future any changes comes then the entire controller is affected.
VIPER : yes sounds wired! but works awesome.
I – Interactor
P – Presentor
E – Entity
R – Routing
VIPER in simple words.
Which contains you display contents and which doesn’t know when and which view is called.
This is the component which decides which view is called when.
This is part where all your business logic is written. Like communicating with a server or to your local database or computing something Big task.
Here your Data persistence comes into the picture. If we using core data then managed object will come here. If SQLite then SQLite operation are written here.
This contains the navigation logic and which will help the presenter to order the views. Segues and navigation controller are most often used routing controllers.
When your project grows you can take each module of a project as a small VIPER individual architecture and modules can grow accordingly.