MVC vs MVVM
MVC has become one of the most popular software design patterns used today. It emphasizes the abstraction of the data layer from GUI interfaces, allowing for faster development. UI designers can focus on HTML/CSS layouts without needing to understand or incorporate data model logic in their work.
While the benefits of using MVC are crystal clear, the definition of what pattern your web app adheres to has become more fuzzy. With the introduction of concepts like MVP and MVVM, design patterns are shifting to an even more strict separation between data and presentation. What classifies as what (MVC vs MVVM vs MVWhatever) is an ongoing debate, however the following is a comprehensive and modern view on this constantly evolving design pattern
MVC stands for Model, View, Controller. Below is a more detailed description of each:
The model refers to the data model. This includes anything you are storing and modifying, including DB tables, documents, etc. Models are representations of objects or componets that your app works with. Examples include users, posts, transactions, notifications, messages, etc. Data models are responsible for representing and storing your data, usually in a relational or non relational database. For more on deciding which database is right for you, see MongoDB vs MySQL.
The view is the presentation layer of your application. It displays the data model to the user through a user interface. The view receives updates from the model as a visual representation of the underlying data object. An example would be a user login page. The login form asks you for your username and password. This really represents an underlying user object (or data model) having a 'username' and 'password' attribute.
While the view receives updates from the model, it has no way of directly communicating with the data layer. The controller handles all of the 'business logic' of your application. It is the bridge between the view and the model. When a user clicks a button, it fires a function in the controller. This function manipulates the model and also interacts with the view to keep both in sync.
This makes sense, but why is it important? Why is this a better pattern than others? The abstraction you get from having your data layer isolated from the view provides a strict separation between the front and back end. This allows for faster development. For example, front end developers trying to add CSS to a web form won't have to worry about working around embedded pHp tags or back end logic. The MVC framework delivers a highly organized code base with a clear separation of concerns.
Model View, View Model
This is where things get interesting. Since the advent of single page web apps, the line of front end / back end responsibilities has become increasingly blurred. Developers are now using things like Angular.js and React.js to harness the power of modern day web browsers and deliver both fast and responsive UI's. Using frameworks like Node.js, developers are taking workloads off the server and processing more client side.
Things have gotten pretty fuzzy in determining what separates MVC from MVVM. Angular even classifies its own pattern as 'MV whatever', as valid arguments exist on both sides. Despite the confusion, it is important to understand the concepts behind these arguments. Such design patterns are valuable for writing less code and clearly separating concerns in your code base.