What is the difference between MVC and MVVM?

Question

Is there a difference between the standard "Model View Controller" pattern and Microsoft's Model/View/ViewModel pattern?

Solution 1

MVC/MVVM is not an either/or choice.

The two patterns crop up, in different ways, in both ASP.Net and Silverlight/WPF development.

For ASP.Net, MVVM is used to two-way bind data within views. This is usually a client-side implementation (e.g. using Knockout.js). MVC on the other hand is a way of separating concerns on the server-side.

For Silverlight and WPF, the MVVM pattern is more encompassing and can appear to act as a replacement for MVC (or other patterns of organising software into separate responsibilities). One assumption, that frequently came out of this pattern, was that the ViewModel simply replaced the controller in MVC (as if you could just substitute VM for C in the acronym and all would be forgiven)...

The ViewModel does not necessarily replace the need for separate Controllers.

The problem is: that to be independently testable*, and especially reusable when needed, a view-model has no idea what view is displaying it, but more importantly no idea where its data is coming from.

*Note: in practice Controllers remove most of the logic, from the ViewModel, that requires unit testing. The VM then becomes a dumb container that requires little, if any, testing. This is a good thing as the VM is just a bridge, between the designer and the coder, so should be kept simple.

Even in MVVM, controllers will typically contain all processing logic and decide what data to display in which views using which view models.

From what we have seen so far the main benefit of the ViewModel pattern to remove code from XAML code-behind to make XAML editing a more independent task. We still create controllers, as and when needed, to control (no pun intended) the overall logic of our applications.

The basic MVCVM guidelines we follow are:

• Views display a certain shape of data. They have no idea where the data comes from.
• ViewModels hold a certain shape of data and commands, they do not know where the data, or code, comes from or how it is displayed.
• Models hold the actual data (various context, store or other methods)
• Controllers listen for, and publish, events. Controllers provide the logic that controls what data is seen and where. Controllers provide the command code to the ViewModel so that the ViewModel is actually reusable.

We also noted that the Sculpture code-gen framework implements MVVM and a pattern similar to Prism AND it also makes extensive use of controllers to separate all use-case logic.

Don't assume controllers are made obsolete by View-models.

I have started a blog on this topic which I will add to as and when I can (archive only as hosting was lost). There are issues with combining MVCVM with the common navigation systems, as most navigation systems just use Views and VMs, but I will go into that in later articles.

An additional benefit of using an MVCVM model is that only the controller objects need to exist in memory for the life of the application and the controllers contain mainly code and little state data (i.e. tiny memory overhead). This makes for much less memory-intensive apps than solutions where view-models have to be retained and it is ideal for certain types of mobile development (e.g. Windows Mobile using Silverlight/Prism/MEF). This does of course depend on the type of application as you may still need to retain the occasional cached VMs for responsiveness.

Note: This post has been edited numerous times, and did not specifically target the narrow question asked, so I have updated the first part to now cover that too. Much of the discussion, in comments below, relates only to ASP.Net and not the broader picture. This post was intended to cover the broader use of MVVM in Silverlight, WPF and ASP.Net and try to discourage people from replacing controllers with ViewModels.

Solution 2

I think the easiest way to understand what these acronyms are supposed to mean is to forget about them for a moment. Instead, think about the software they originated with, each one of them. It really boils down to just the difference between the early web and the desktop.

As they grew in complexity in the mid-2000s, the MVC software design pattern - which was first described in the 1970s - began to be applied to web applications. Think database, HTML pages, and code inbetween. Let's refine this just a little bit to arrive at MVC: For »database«, let's assume database plus interface code. For »HTML pages«, let's assume HTML templates plus template processing code. For »code inbetween«, let's assume code mapping user clicks to actions, possibly affecting the database, definitely causing another view to be displayed. That's it, at least for the purpose of this comparison.

Let's retain one feature of this web stuff, not as it is today, but as it existed ten years ago, when JavaScript was a lowly, despicable annoyance, which real programmers did well to steer clear of: The HTML page is essentially dumb and passive. The browser is a thin client, or if you will, a poor client. There is no intelligence in the browser. Full page reloads rule. The »view« is generated anew each time around.

Let's remember that this web way, despite being all the rage, was horribly backward compared to the desktop. Desktop apps are fat clients, or rich clients, if you will. (Even a program like Microsoft Word can be thought of as some kind of client, a client for documents.) They're clients full of intelligence, full of knowledge about their data. They're stateful. They cache data they're handling in memory. No such crap as a full page reload.

And this rich desktop way is probably where the second acronym originated, MVVM. Don't be fooled by the letters, by the omission of the C. Controllers are still there. They need to be. Nothing gets removed. We just add one thing: statefulness, data cached on the client (and along with it intelligence to handle that data). That data, essentially a cache on the client, now gets called »ViewModel«. It's what allows rich interactivity. And that's it.

• MVC = model, controller, view = essentially one-way communication = poor interactivity
• MVVM = model, controller, cache, view = two-way communication = rich interactivity

We can see that with Flash, Silverlight, and - most importantly - JavaScript, the web has embraced MVVM. Browsers can no longer be legitimately called thin clients. Look at their programmability. Look at their memory consumption. Look at all the Javascript interactivity on modern web pages.

Personally, I find this theory and acronym business easier to understand by looking at what it's referring to in concrete reality. Abstract concepts are useful, especially when demonstrated on concrete matter, so understanding may come full circle.

 

Solution 3

MVVM Model-View ViewModel is similar to MVC, Model-View Controller

The controller is replaced with a ViewModel. The ViewModel sits below the UI layer. The ViewModel exposes the data and command objects that the view needs. You could think of this as a container object that view goes to get its data and actions from. The ViewModel pulls its data from the model.

Russel East does a blog discussing more in detail Why is MVVM is different from MVC

Solution 4

For one thing, MVVM is a progression of the MVC pattern which uses XAML to handle the display. This article outlines some of the facets of the two.

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.

Solution 5

Microsoft provided an explanation of the MVVM Pattern in the Windows environment here.

Here's a crucial section:

In the Model-View-ViewModel design pattern, an app is composed of three general components.

• Model: This represents the data model that your app consumes. For example, in a picture sharing app, this layer might represent the set of pictures available on a device and the API used to read and write to the picture library.

• View: An app typically is composed of multiple pages of UI. Each page shown to the user is a view in MVVM terminology. The view is the XAML code used to define and style what the user sees. The data from the model is displayed to the user, and it’s the job of the ViewModel to feed the UI this data based on the current state of the app. For example, in a picture sharing app, the views would be the UI that show the user the list of albums on the device, the pictures in an album, and perhaps another that shows the user a particular picture.

• ViewModel: The ViewModel ties the data model, or simply the model, to the UI, or views, of the app. It contains the logic with which to manage the data from the model and exposes the data as a set of properties to which the XAML UI, or views, can bind. For example, in a picture sharing app, the ViewModel would expose a list of albums, and for each album expose a list of pictures. The UI is agnostic of where the pictures come from and how they are retrieved. It simply knows of a set of pictures as exposed by the ViewModel and shows them to the user.

View more solutions

Comments

[BoltClock]

Note that while MVVM was coined by Microsoft, plenty of non-Microsoft developers and projects have begun to adopt this pattern. This comment was brought to you by the spite-the-MS-haters department.

[JWP]

Having worked with MVVM for a long time, my first brush with MVC was frustrating, until I learned I could pass ViewModels back and forth to the browser using binding techniques found in MVVM. But as Joel said above the only way to get state back from the browser is by posting the changes in a form (which uses name/value) pairs. If you don't understand this point well. You will have a hard time in MVC. Just look at the controller as a dependency injector for the view and you're all set.

[Ricardo]

Such an upvoted question on high-level [design patterns]. I would kindly like to suggest the use of diagrams on the answers.

[Raydot]

Also a re-wording of the question to reflect the fact that the question is asked in the context of Microsoft technologies...although the accepted answer sort of is not.

[Tereza Tomcova]

Here's an archived version of Joel's article: web.archive.org/web/20150219153055/http://joel.inpointform.n‌​et/…

[Ahmad Ismail]

Unlike the MVC method, the ViewModel isn’t a controller. It instead acts as a binder that binds data between the view and model. Whereas the MVC format is specifically designed to create a separation of concerns between the model and view, the MVVM format with data-binding is designed specifically to allow the view and model to communicate directly with each other. hackernoon.com/…

[Daniel Auger]

I think the paragraph you quoted sums it up nicely IMHO. An aspect of the ViewModel is that it is a flattened/altered version of the model for the view. Many other MV* patterns bind against the real model.

[Esteban Vergara]

MVVM, strictly speaking, is Presentation Model, though MVVM is becoming the preferred name for the WPF specific realization of the pattern.

[DaniCE]

The sentence "The controller is replaced with a View Model" is not correct. In MVVM what does the role of the controller is databinding (or binding by convention if you use that).

[ktutnik]

+1. The term is the correct one i think. but about creating hybrid M-MProxy-V-C isn't that too much separation? i think it would be enough using M-V-C whereas M is a Model with full support of Binding. ;)

[Jeff]

MVVM will only make sense when using WPF's two way data binding. Otherwise MVC/MVP etc would be sufficient.

[Debajit]

"Many other MV* patterns bind again the real model”? Really? I thought the view was always supposed to bind to the controller in MVC, no matter what.

[Sled]

@Jeff wouldn't MVVM also apply to JavaFX Script?

[Jeff]

@ArtB sorry I have no idea about Java.

[Tomasz Zieliński]

Nocturne: In classic MVC, View doesn't have much to do with controller, it binds mostly to Model. Think of it as of a robot - Model represents the position of robot's joints, View is a LCD monitor on which you see the robot, Controller is e.g. keyboard. In such setup, View depends on Model, i.e. the spatial position of robot, that you can see on the monitor is a direct representation of Model.

[Tomasz Zieliński]

+1. As I commented above, I think that MVC is used to architect the whole (web) application, while MVVM is used inside View component of MVC.

[Tomasz Zieliński]

@ktutnik: Model usually sits on the server, whereas ViewModel lives on the client. So it's no feasible for HTML to bind directly to server-side Model. Therefore we need ModelView which acts as a local, unsaved working set of data extracted from model using e.g. AJAX/JSON.

[Gone Coding]

@Tomasz Zielinski: True, but "where they are used" was not the question (or the point of my answer). My point is that controllers are still useful in MVVM.

[Tomasz Zieliński]

I agree. My comment was caused by sudden enlightement and not because I disagreed with you.

[sll]

@DaniCE: Josh Smith: If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. …

[Anish]

We also used controllers to control the "flow" of views in a wizard-like UI.

[tereško]

The cause of confusion comes from what ASP.NET MVC calls "ViewModel", because, when implementing Rails interpretation of MVC, there is no view, only templates while people call "views". In ASP.NET MVC the ViewModel actually a full implemented View from Model2 MVC pattern (active view which requests data from model layer and manipulates multiple templates based on that data).

[Om Shankar]

@DaniCE, correct, have experienced that! However, 10 from them, 11th from yourself, but where does the 12th it come from - just asking!

[Justin]

What you are saying makes perfect sense (the VM shouldn't contain logic), however I'm struggling to see how it would work in practice - for example what unit-testable piece of logic is executed when the user clicks on a button? How about when the user modifies a text box which is two-way databound to a property on the ViewModel?

[Gone Coding]

@Justin: I see my wording of that sentence is a little ambiguous. I actually mean unit-testing for all components is more easily supported, not specifically just improving testing of ViewModels (which as you point out don't actually do that much in MVCVM... which is what you want). The real benefit of controllers is that you are actually removing most of the requirements for testing from the ViewModel (where people keeps shoving controller logic) and putting it where it can be tested (mainly Controllers and Models). The reuse comment is specific to the VMs in that sentence. I have edited it.

[jpic]

I don't understand what's the difference between MVVM and MVC with Controller Service pattern ......

[Gone Coding]

@jpic: MVVM does not normally encourage separation of controllers (which I am encouraging). MVC also uses ViewModels, as well as models, so should it not also be called MVCVM and both follow the same pattern... hmmm? :)

[subsci]

Please elaborate on the role of ViewModel in two-way data binding. The Controller gets and puts ViewModels from and to the View. What type of Entity (Controller?) mediates getting and putting between the ViewModel and (one or more) Models?

[Gone Coding]

@subsci: Two-way binding, in MVVM, is purely a way of mirroring values in both the View and View-Model allowing the changes to reflect elsewhere in the View(s). Binding direct to actual data sources in a GUI app can be quite a fragile connection (e.g. not resistant to comms failures), so better to persist data under the specific control of a Controller, e.g. in response to a Save option/command. Controllers can instantiate data connection objects as and when needed (like EF does). I am assuming you will persist your data with WCF RIA services?

[Arialdo Martini]

MVC did not originate on the web. Trygve Reenskaug introduced MVC into Smalltalk-76 in the 1970s.

[Dan Bechard]

@OmShankar The 11th isn't from yourself. There are 10 total people, and 12 total opinions. The adage is meant to imply that the definitions of these patterns is so open to interpretation that at least two people will be confused enough to have more than one opinion.

[Dan Bechard]

Even if it were changed to "MVC was popularized through web application design." I would argue that this is speculation without proper citation.

[Lumi]

Arialdo: Thanks, I didn't know about Smalltalk-76. (Played with other toys back then. :) Jokes aside, it's interesting how old some of these concepts are. - @Dan, what I wrote is: "[MVC] may have been there before [the web], but the web is how it got popularized to the masses of web developers." I still think that's correct. I don't have a citation for it, but then I don't feel I need one because that MVC mass popularizing is part of my personal experience when I started as a web developer at the beginning of the last decade. Apache Struts was en vogue back then, with lots of beans for MVC.

[Dan Bechard]

@Lumi I was agreeing with that statement, but it directly conflicts your previous sentence "The first acronym, MVC, originated on the web." which states a web origin as fact. It's like saying "The sky is purple. (Actually the sky is blue, but on rare occasions it has a purple-like hue.)" :P

[yoel halb]

So basically you are not disagreeing with TStamper's answer, which is also what appears to be the description of Microsoft itself at msdn.microsoft.com/en-us/magazine/dd419663.aspx, instead you propose that MVVM is wrong and instead one should use MVCVM, also since many claim that a controller is not one to one (see stackoverflow.com/questions/1593976/benefits-of-mvvm-over-mv‌​c/…) you would probably have to call it MVPVM

[yoel halb]

@DaniCE Well this is actually the point of WPF's data binding, and the Microsoft invented MVVM, in that one can bypass the controller completely, (claiming the sentence "The controller is being replaced with a View Model" to be incorrect just because there is a controller behind the scenes, is basically like claiming a statement "Higher level language replace the use of cryptic machine code with more readable ones" to be incorrect because behind the scenes machine language is still being used...)

[yoel halb]

@PeterTseng While you are right that in situations like ASP.NET MVC the controller is used to manipulate the view and not the other way around, however the definition of MVC by the gang of four (as quoted in blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc) appears to be the other way around as they write "A view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller", and it is like the business tire in 3 tire application

[yoel halb]

@PeterTseng Although in modern terms this definition would more closely match the MVP pattern than what is considered today as the MVC pattern sucha as in ASP.NET MVC, we can still differentiate it from MVP, by saying that in MVC the view is decoupled from the controller, not being a one-by-one relationship, and only ONE of them knows and decides about the other, however whether the view is deciding which controller to use or the controller deciding which view to use is not part of the MVC pattern specification, although I would find more natural say that this decision belongs for controller

[yoel halb]

@Nocturne What daniel appeared to say is that while officially all MV* should use a separate VM, many developers just ignore it, and pass the actual model, and in fact nothing in the specifications for example of MVC disallows it, however in MVVM one must a VM being responsible fot the transition between the model and the view

[DaniCE]

@yo hal Your reply is about a quite old comment. Today I would prefer to say that Model - View - ViewModel is a different pattern from MVC and its components does not match exactly (and has no sense try to match them). If they matched exactly the two patters will be the same and MVVM will not be necessary.

[Mike Bethany]

I've found them both lacking. MVC frameworks like Rails handle even simply joins poorly (try building a selection on a relation using a scope from that associated record) while Microsoft's MVVM in trying to fix some problems in MVC ends up being painfully coupled and klunky.

[JWP]

I disagree with the concept that the controllers are anything more than 1) A route handler and 2) The minder of he ViewModel. From a controller perspective the VM only needs two methods 1)The null CTOR which MVC must have anyway, and 2) A POST method. The controller is just a traffic cop, it handles events either newing up a viewmodel or calling it's Post method. The view model then can either contain models, create models, has collections and keeps the state. It can also contain business logic. Putting a bunch of code into the controller doesn't make sense to me.

[JWP]

Why would the viewmodel replace the controller. The very name of controller indicates it's purpose which is to be a mediator of the View and the View Content, it's a traffic cop and that's all it is.

[Gone Coding]

@user1522548: You are certainly entitled to disagree. My opinion was/is based on a wide variety of requirements for logic separation and simplification of ViewModels. MVVM encompasess Silverlight, WPF and web apps, not only the simple case of ASP/MVC you reference. Thanks.

[JWP]

I would say it like this: The model is closet thing to DB schema. When a query is run it can project the data into strong types at the model layer. The viewmodel is collections of things, including model objects, but can and does hold view state with respect to the data. The controller is simply a traffic cop between the viewmodel and the view and of course the view is only concerned with view states.

[JWP]

MVC is not "essentially one-way communication" as browsers issue Gets and Posts all the time. Both Gets and Posts can change field values found in the query string. This gives browsers ample opportunity to send information back to the controller. MVC was built on top of HTTP 1.0 which always had two way communication in mind.

[JWP]

The view does indeed "read" the model data because it's already been put there by the controller. I like to refer to it as a "data injection" by the controller as it's really the controller that is in charge. All the view does in render and fire events in my mind.

[JWP]

In 2009 this answer was probably a good one but today, there is no debate as even HTML Helper controls from MSFT allow for binding using the infamous "For" helpers. Knockout is all about data-binding on the client side.

[JWP]

Agreed. The Viewmodel in MVC "IS" the state machine for the view. It contains the datacontext and tracks all selected item information as well as can contain all validation logic using the IValidatableObject interface. The ViewModel interfaces with the DB at the model layer which can use strong typed models. MVVM in WPF IS the controller of MVC. But the controller of MVC is much cleaner, it is essential a routing handler.

[JWP]

I am a strongly typed bigot, for me the Viewmodel approach to MVC is the only way to fly. This means that much if not all of the states and datacontext is moved to the VM layer. In my projects, the controller is just an injector of viewmodels (either new ones or altered content due to a post). The VM in my projects uses the EF layer extensively because I've found EF can do anything and do it well with strongly typed models. But what I've noticed in the MVC world is that there's still a huge contingency for non-strong typed solutions. This is a hold over from query string parsing.

[Gone Coding]

@user1522548: Coding by convention (i.e. not strongly typed) is one of the more powerful features of MVC, but if you don't use/like it then you will obviously find other solutions. I suggest you compile your ideas into an alternate answer to this question and get some feedback :)

[JWP]

Ya I use that too, but for tables with thousands of fields why bother? EF can give me strong types of entire database in 2 minutes. I work with an old school asp.net guy who still does all that stuff you know, Name/Value pairs all typed in for everything he does. He likes what EF does but doesn't yet grasp the benefits. Couple EF with LINQ and I'll never touch a database again. But just look at some of the newer javascript based frameworks. It's all about databinding and we're not talking about strings, were talking about client side strong type binding.

[Gone Coding]

@user1522548: Please post your concepts in an answer for review as suggested. comments are not appropriate for broader discussions. Thanks.

[JWP]

Thanks TrueBlue didn't mean to offend anyone, and am new to the protocol here.

[Mohamed Emad]

@TomaszZielinski M(MVVM)C

[eran otzap]

your blog post kinda resembles Prism's mvvmp

[Gone Coding]

@eran otzap: do you have a recent reference you can link to? I was working heavily with Prism at the time, but that was so many years ago now.

[eran otzap]

It's like a personal opinion since the presenter holds references to VM(s) . and itself is responsible for populating their properties. (Including hooking up logic to commands exposed by the VM.) So in fact they remain a dumb container holding most of the memory and the presenter creates thous containers aside from wcf proxies and such and conducts logic on the presentation layer.

[Gone Coding]

@eran otzap: Although I think the OP was asking for answers relating to MVC and client-side MVVM, my prior work with Silverlight, WPF (both with PRISM) lead me to consider controllers to always be a required part of the equation. The only time you would not consider it is with really basic MVVM binding like KnockOut which is really only about sharing property changes.

[eran otzap]

I agree , i just compared mvvmp to mvc because i see much similarities between a controller and a presenter , a presenter is a kind of controller which aside from separating the how , he is responsible for updating models / ViewModels which intern affect the view

[Gone Coding]

Can you clarify item 6? I realises you are covering ASP.Net only, but it appears to be adding an unwanted dependency to the ViewModel. (e.g. knowledge of where the data comes from/goes to). A code (pseudo-code?) example would be good to clarify this answer and show which parts are server-side and which are client-side.

[Gone Coding]

IMHO I would argue that "making controllers more reusable" is too broad a statement and counter-productive for general ASP.Net "controllers" (i.e. not the business logic layer) as those controllers typically contain the parts of the application that are application-specific. It is the Views, Models, ViewModels and business logic that need to be reusable. I would have thought treating the business logic modules as service providers, not as controllers, would be a better option.

[gcdev]

Thanks Lumi. This made so much more sense to me than the other answers. Is it correct? I have no idea. But from my perspective it was at least coherent.

[Alappin]

@MohamedEmad: I even got further enlightenment as M-C(VM)-V. Here the controller just keeps a view model for the view. Surprisingly enough, this is how I have been coding my angular apps.

[KeyOfJ]

@Tomas Zielinski MVVM is a pattern that can be used independently from an MVC application. We use the MVVM pattern with Javascript client side code. Our AJAX calls into MVC patterned Web API. I see them as two distinct patterns with different purposes. They can be used in conjunction with each other but one part does not replace the other.

[MattE]

Wow...so both MVC and MVVM came from SmallTalk?? They were way ahead of their time apparently...

[Richard Nalezynski]

Note that while article referenced applies to development with the Microsoft Stack - Specifically Windows Phone - and XAML, it's doesn't have to be.

[Terrence Brannon]

What 'web development' terms 'MVC' is nothing more than separation of concerns and not the authentic MVC that preceded the web.

[Michael Puckett II]

I apologize but disagree with the MVVM interpretation. A ViewModel has no idea about a View or what a View will look like or how it will respond and a Model likewise has no idea of a ViewModel. In fact, a View shouldn't even know of a Model either, just a ViewModel. Model should represent data and application state, ViewModel should translate the state to UI capable data (I recommend all primitives at this point) and a View should react to the ViewModels translation. The data will often be the same but it should still be wrapped and re-delivered via a ViewModel and no controllers exist.

[Sentinel]

Agree with Arialdo, MVC app types were in the early WinForms visual studio project templates, back when the web was still a green screen dial up

[Cross_]

Lost me at "MVC, originated on the web". Please don't guess when answering questions.

[Esteban Vergara]

Actually, saying it originated from Martin Fowler's Presentation Model isn't accurate. It's very difficult to determine which came first, but both patterns (allowing that they are really the same pattern) were arrived at independently and at roughly the same time.

[Esteban Vergara]

I stated this, in 2009, because far too many people in the community accepted this answer. I said it was debatable, because MVVM and Presentation Model really are the same pattern by different names. Tanks to the popularity in WPF, it's often called MVVM in other frameworks today, but either name is accurate.

[Scott Buchanan]

Great explanation and clearer than many others here which get side tracked from directly answering the question. As to those who question whether it was popularized more recently, see: books.google.com/ngrams/…

[Luis]

But you are talking about the "ViewModel" in Asp.net, not about the MVVM design pattern. Two different things.

[ankush981]

Amazingly detailed and accurate answer! Made it crystal-clear for me. :-)

[MarredCheese]

"learning it can be very confusing as you'll find A LOT OF BAD information on the net." Yep. As someone who seems to have a lot of experience with these design patterns, do you know of any good tutorials/guides?

[Michael Puckett II]

To be honest, my MVVM knowledge has been through years or trial and error and using / doing it various ways based on team efforts. I recently (2 years ago) was able to put my own experience into a summarized game plan and lead a team start to finish doing so and we were extremely successful. That said, I can't point you into any one spot and apologize. I can say that you are correct, because of the various opinions it is very confusing but, IMO, with MVVM it's to be as generic as possible. Make ViewModels capable of allowing views to bind and work with data strictly but for ANY view...

[Michael Puckett II]

In other words NEVER make the ViewModel assume a View will look or act in any way. ViewModel, to me, are best used like an API, but with strict communication. Follow the game plan for binding, editing, commanding, etc. If the View needs extra logic to function a specific way, that has nothing to do with the app or data (such as an animation or a dropdown box..) then that logic belongs in the View tier somewhere somehow. Again, there's a plethora of opinions and this is just mine but I have a strong background here and a solid track record so far.

[Michael Puckett II]

I have example apps that I don't mind sharing and or wouldn't mind setting up a simple show and tell for you or anyone else if wanted or curious.

[Etherman]

This answer highlights the problem with the name "MVVM" - it should be "VVMM" or "MVMV" - M-V-VM has the relationships completely the wrong way around!

[Sukma Wardana]

@MichaelPuckettII Hi, would you mind to share your example apps? I'm at the beginning to learn MVVM and really want to learn from you, how I could contact you? thanks

[Michael Puckett II]

No problem, [email protected]

[neonblitzer]

There's a great answer under all the flavor text here... With some formatting and throwing out small talk between components this could be the best one on this page.

[Admin]

Best explanation

[Darryl Morley]

A great explanation, thanks!

[Kedar]

Well explained and highlights underlying difference between MVC and MVVM

[khargoosh]

Blog post/site has Gone Missing. @GoneCoding have you moved it?

[Gone Coding]

@khargoosh Lost all my hosted domains and content. Had to find a new provider. Will link to the archive on archive.org. Thanks for noticing! :)

[Mr Rubix]

Thanks, you made my day kind gentleman

[I Want Answers]

@gcdev My guess is he is correct because Vue refers to their object instances as VM (view-models)

[Ahmed Elsayed]

The best explanation I've found so far!