The primary reason that modern architectural patterns have moved away from MVC is that the Controller in MVC generally embodies too much application code and becomes unwieldy, thereby being difficult to test. This has led to patterns that not only replace the Controller with something else, but that add multiple layers in its place to further establish a separation of concerns within an application.
In the world of iOS, Apple's mobile operating system, MVC was long encouraged as the pattern to follow. More recently, however, many iOS developers have moved away from pure MVC and have adopted patterns that establish more than just three layers within an application's architecture. One of these patterns is VIPER, which stands for View, Interactor, Presenter, Entity, and Routing (or Router).
Let's briefly cover what each of these components is:
- View: Just as with MVC, the View represents the user interface.
- Interactor: Contains the business logic for a particular behavior and corresponding View within the app. An Interactor is similar to a Controller in MVC, but it may interact with multiple Models and is not constrained to only one Model.
- Presenter: Contains logic for the View, just as with MVP.
- Entity: Another word for Model, simply used to achieve the E in the VIPER acronym.
- Routing: Each request in an app is made using a unique call, and in the case of a web application, a URL or route from the browser is used to make an application request. This layer may also be called the Router.
It is evident from the description of the components in VIPER that they do not actually flow in the order of the acronym itself, but rather are ordered as such for aesthetic purposes. The diagram below shows the true flow of the VIPER pattern, along with representations of the browser and the database to supplement the understanding of this flow:
(Diagram from http://khanlou.com/2014/03/model-view-whatever/)
So far, we have covered the traditional MVC architectural pattern, MVP, MVVM, and the more recently contrived VIPER pattern. What should be clear is the patterns that have followed MVC do not represent a full paradigm shift, but rather a restructuring of the traditional Controller component to embody more clarity, and in the case of VIPER, to be divided into a further separation of concerns. The general paradigm is not lost in these other patterns because the concept of the Model and the View remain intact. This trend is what has led to the generalized paradigmatic term Model-View-Whatever or MVW.
What we are left with is a multitude of architectural patterns that have been conceived as abstractions of MVC. So, what pattern should you choose for a JavaScript SPA? This is a highly subjective topic, so the best answer is that you should choose a pattern based on the type of app you are building, and also based on what makes the most sense to you and what you are most comfortable with.
The software libraries and frameworks you choose to work with should also factor into what pattern you use. In that regard, let's take a look at how AngularJS has adapted MVC for its own version of MVW.