# MVC vs MVVm

**URL:** <https://metaruby.com/t/mvc-vs-mvvm/183>\
**Category:** General Programming\
**Tags:** rails, volt\
**Created:** [June 24, 2015, 6:34pm UTC](https://metaruby.com/t/mvc-vs-mvvm/183 "2015-06-24T18:34:20Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![AstonJ](https://metaruby.com/user_avatar/metaruby.com/astonj/32/8_2.png) [@AstonJ](https://metaruby.com/u/AstonJ)\
**Post date:** [June 24, 2015, 6:34pm UTC](https://metaruby.com/t/mvc-vs-mvvm/183/1 "2015-06-24T18:34:20Z")

</div>

Anyone have any thoughts on MVC vs MVVm (Model View ViewModel)?

Here is an excerpt from my forthcoming blog post about Volt:

> [@](#):
>
> ### Views, ViewModels, Controllers and Models = MVVm
> 
> Because Volt is a full stack framework that includes a reactive front end framework, with plans to be multi-platform ready as well, the architectural paradigm shifts from the familiar MVC architecture that we are used to in Rails.
> 
> Volt is more of a MVVm framework - which stands for Model View ViewModel. If you’re new to MVVm it’s worth pointing out that different frameworks call the ViewModels different things; some call them ViewModels, others (like Cocoa) call them ViewControllers. Volt has opted to simply call them Controllers and you’ll hear them referred to interchangeably - so when you hear the term ViewModel think Controller, and vice versa.
> 
> ViewModels (Controllers) are used for the context of the view at all times. In Rails, the controller runs first and sets up all your instance variables which it then passes down to the view. In Volt the controller **persists for the entire lifetime of the view** so you can continually call methods on it, and through this you can keep the state of your view in sync at all times.
> 
> Here’s a good explanation:
> 
> _“The main thrust of the Model/View/ViewModel architecture seems to be that on top of the data (”the Model”), there’s another layer of non-visual components (”the ViewModel”) that map the concepts of the data more closely to the concepts of the view of the data (”the View”). It’s the ViewModel that the View binds to, not the Model directly.”_
> 
> What this basically means is that Views do not interact directly with Models apart from via the ViewModels, and the ViewModels don’t know that much about the Views - all they are interested in is telling the Views what needs to show, getting user feedback and then (perhaps after speaking to the Model) pushing any further info or changes back to the Views. The beauty of this is that the Model and the ViewModel code can be reused for lots and lots of different Views (/platforms). So a single ViewModel could have a View for a web app, another for iOS, another for Android and others for desktop applications for the various operating systems such as OS X, Windows, and Linux!
> 
> This is exactly why so many feel the MVVm architecture is the architecture for the foreseeable future, because there is a high rate of code reusability while allowing a **fully native** experience on several different platforms - perfect in this age of multiple devices that go beyond just websites!

(Any feedback welcomed.)

What do you think of the different architectures and do you have a preference?