Home » Javascript » 4 Reasons To Drop MVVM

4 Reasons To Drop MVVM

The MVVM design pattern has been around for quite a while now.  It has a lot of strengths when done correctly. But, I believe the time has come to recognize that MVVM has a lot of shortcomings that point to its demise.  Since I primarily develop web applications, I will keep this discussion centered on the use of MVVM in web applications.  The use of MVVM for desktop may or may not have these same issues.

I realize that for some of you, the very suggestion of dropping MVVM will invoke a negative emotional response.  Some very smart people have quit their job at the suggestion that MVVM and its close cousin two-way data-binding, be abandoned in favor of another way.  But just for a few minutes, I would like for you to stop treating programming as a religion and consider the possibility that there may be a better way.

image

History of MVVM

MVVM was originally created by John Gossman to support the XAML syntax used to create Windows™ desktop applications and Silver Light applications.  Its main advantage has always been that it provides an easy way to decouple the View code from any business logic that might need to run.  Because of this decoupling, our applications become much easier to unit test.

The next major implementation of MVVM that I can remember is Knockout.  It is the knockout framework that introduced me to MVVM and I have to say it is also the only one I feel like actually got it right.  By that I mean that it actually did what it was advertised to do.  Maybe that’s because of all the implementations I’ve used, Knockout is the only one that ONLY implemented MVVM rather than making it part of a larger framework.

Definition of MVVM

I’ve written about MVVM before where I’ve explained more completely what MVVM is.  But just so we have a working definition of what I mean when I talk about MVVM, let’s define it this way.

MVVM is a design pattern that uses two-way data-binding to get data in and out of the presentation layer, referred to as the View, without the programmer needing to do any more than specifying that this should happen in the view.  MVVM is also able to have data elements and functions in the “ViewModel” track changes so that anything that is dependent on other data is automatically recalculated without the programmer having to write a lot of code to make this happen.  This creates a model that is able to respond to events in the view, but is primarily data centric rather than event centric has we have often reasoned about our applications in the past.

It sounds great.  And when it works it is.  But that’s the main problem, it hardly ever works well.

MVVM Done Right is Slow

If you’ve had any experience or paid any attention to the implementation of MVVM using JavaScript, you will realize that the number one problem with MVVM is that it is a memory hog and performs poorly for all but the most trivial of applications.  In fact, for all of the popularity of Angular JS, the biggest complaint has been around the implementation of the data-binding.  In a large application, you might need to loop through the data multiple times to make sure it has all recalculated correctly.  If you just use the framework and let the framework deal with your sloppy code, this can make the system incredibly slow.  If you actually pay attention to what you are doing, it takes longer to implement than if you had chosen some other design pattern.

But doing that means we have not moved on to…

MVVM is Hard to Implement

Recognizing that looping through the data until it stabilizes may not be a good idea, the framework designers have developed rules such as, “We’ll only run the digest cycle once.”  and “We’ll only run it when some user interaction has occurred.”  Well, OK.  That sounds good.  At least now it will be obvious that I have a problem.  But this is where the trouble begins.  If I can’t rely on my data, and ultimately my view, responding to changes in my data correctly, I am left with having to only partially implementing MVVM so that I can work around these limitations and using other means to make sure my view is updated correctly.

This is to say nothing of many frameworks just not working as you would expect them to.

MVVM is Hard to Reason About

Again, in all but the most trivial of applications, and because of the optimizations that various frameworks have tried to implement, MVVM becomes difficult to implement.  As I’ve tried to explain MVVM to others and even as I’ve tried to implement it myself, I’ve found that the simple act of keeping the view stuff in the view layer and the data stuff in the data layer and making sure it all updates appropriately has me, at times tearing my hair out.  Many times this is caused by incomplete implementations.  But if being hard to implement means it is hard to reason about, maybe we shouldn’t be using it to begin with.

MVVM is Overkill

But it does work sometimes.  In really simple CRUD applications, it works great.  None of the problems I’ve mentioned.  And this is the great seduction of MVVM.  You try it on some small application and you get excited.  Like a gateway drug, it lures you in.  And when you finally go to implement it on some larger application, you find out that it really doesn’t scale all that well.  And on that small app you tried it on, couldn’t you have done that just as easily using another design pattern?

Where to Go from Here

As I was reviewing these arguments with a co-worker this week, he asked, “Are you saying we shouldn’t be using MVVM?”  And my answer might surprise you.

I said, “Given the two models we have to work within the framework we are currently using, MVVM is the best choice.”

However, what we might want to consider is moving to another framework that provides a better design pattern.  There are several “One-way” design patterns that intrigue me.  The first is the basic Flux pattern that React tends to use.  Done correctly, this uses events to achieve the decoupling we all should be striving for.  At its core, it is basic MVC.

The second one, which is very flux like, is RxJS.  I’m still wrapping my head around how I to use it in an application and honestly don’t know enough about it at this point to say any more than that it looks interesting.

And even if we decided to move away from MVVM, I think using two way data-binding between the view and the ViewModel is good.  I just think the ViewModel shouldn’t try to re-compute the values as part of what it does. Leave that to the developer to control.  The problem is, trying to get existing systems that implement two-way data-binding to only work at that level would not work correctly.

 

Other places talking about MVVM

 

Other post in Javascript
Summary
4 Reasons To Drop MVVM
Article Name
4 Reasons To Drop MVVM
Description
The MVVM design pattern has been around for quite a while now. It has a lot of strengths when done correctly. But, I believe the time has come to recognize that MVVM has a lot of shortcomings that point to its demise.
Author
DMB Consulting, LLC

About Dave Bush

Dave Bush is a "Full Stack" ASP.NET developer currently specializing in Angular but also capable of using ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.

Leave a Reply

23 Comments on "4 Reasons To Drop MVVM"

avatar
  Subscribe  
newest oldest most voted
Notify of
Pete
Guest

Your argument seems to be that the Angular implementation of MVVM is flawed. Having successfully developed and deployed MVVM applications in any number of platforms, performant applications, I am disappointed that you conflated the two sides.

Dave Bush
Guest

Angular isn’t the only implementation I’ve used. I’ve used several, including Angular 1.

I’ve also developed several successful projects using MVVM. But being able to do something successfully, doesn’t mean it is the best solution.

This is my experience. You have a different experience. Time will tell.

Alex
Guest

MVVM is overused, I see people using it in all sorts of applications where it’s not needed. They use it because they want to be the cool kids on the block using the latest hipster trend of the week.

Most of these MVVM frameworks / libraries were introduced to solve a specific problem, then got moulded into something more generalised.

It’s gotton so bad that people are now inventing UI/UX/SS problems to justify the use of MVVM and secure their jobs….

Shad
Guest

Isn’t that true of every API/Framework/Language ever?

People invest a lot of time an effort into learning an API/Framework/Language.

The last thing they want to hear is that effort is worth nought.

trackback

[…] 4 Reasons To Drop MVVM (Dave M. Bush) […]

thornik
Guest

My most apps have shorter version: “model-view” and that works! Because “model” is adapted for View as well as storing in DB. Not a rocket science!

Dave Bush
Guest

Are you able to write unit tests with that framework?

thornik
Guest

Yep, why not? “model” can also have business logic. Plus static class-helper for operations. Finally you get rid of “ideal MVVM structure” and have more practical classes.

Dogma Hunter
Guest

I’ld say your business logic belongs in your business layer, not in your model.
But we use a not-so-traditional version of MVVM as well. We call it “MVVMC”.
The ‘C’ is, off course, a Controller. The controller takes care of the actual business calls, thread management and is responsible for getting models in and out of the business.
It’s kind of the bridge between the UI and the business.

Stephen Cleary
Guest

I’ve fallen in love with Redux. It’s a sort of simplified variant of Flux, where all the app’s data lives in a single store – a single, unambiguous place for all state updates. No cross-component message passing, no message bus tying everything together – it’s very clean!

Dave Bush
Guest

Yes, I like the Flux model, haven’t tried Redux yet but it is on my list.

kmote
Guest
Dave, the conclusions of this article appears to be rather web-centric (i.e., focused on technologies such as Knockout, Javascript, Angular, etc). But in the realm of .NET, and C# in particular, graphically intensive desktop applications have limited options. If you need more flexibility than Windows Forms, you’re pretty much forced to adopt WPF which, as I understand it, is tightly coupled with MVVM (irony intended). I would love to have another option, and have often wished that MS would provide one, but that doesn’t appear to be on even the most distant horizon, unfortunately. Or is there an alternative that… Read more »
Dave Bush
Guest

Yes web centric because this blog is almost entirely web centric.

kmote
Guest
Yes, and please understand, my comment wasn’t meant as a criticism. I’m just trying to translate your thoughts and the suggestion of this post into my world. (I’m fairly new to your blog, and was unaware of its theme.) To be quite honest, before today I didn’t even realize that MVVM was ever used outside of XAML-related technology. That is quite eye-opening. But what I really want to ask you, given your experience in C#, is: do you think it is possible to “Drop MVVM” in the WPF world? (Because believe me, I would love to, but I don’t see… Read more »
Dave Bush
Guest

I don’t have any experience one way or the other with WPF. So, I really can’t help you. But maybe one of the other readers can?

Dogma Hunter
Guest

I don’t think anything stops you from binding your data the “old school” way?
The bigger question however, is why would you want to?
MVVM is pretty much baked into WPF itself.

redcurry
Guest
I haven’t been able to drop MVVM from the WPF world, but I recently discovered a way to make things better. I used to have too much logic in my view models, so they were big and unmaintainable. What I do now is forward any property changes to a “controller” object (passed in to the view model through dependency injection). I also forward commands to the controller object. Now the only job that view models have is binding (back and forth from/to the view) of properties and commands. This has made my view models much simpler to understand because they… Read more »
luisgimx
Guest

Isn’t that the way MVVM works? views haven’t business loginc, only pure “view” logic, the ViewModel is the one having business logic.

Dave Bush
Admin

Actually, “the ViewModel is the one having business logic” is a misconception. The ViewModel SHOULD only have data that needs to be presented or received from the View. In a well built system, the actual business logic would live in another layer. MVVM, MVC, or any other MV* framework is ONLY about the view. Business logic doesn’t belong in MV* at all!

Jim L
Guest
MVVM as implemented in WPF does seem like overkill. To have a separate class monitor and control the view class does not seem very object oriented. The xaml code calls directly into the viewmodel property to get its data to display and the viewmodel should be getting its data from the data ‘model’ object. Then the view writes changes over into the viewmodel who relays it to the model object. As a result, the viewmodel class needs to be highly specific to serve both the view and model classes. This sounds like a highly coupled situation which is a sign… Read more »
Mike
Guest

How could the code behind of the view bind to the view?

Dogma Hunter
Guest

MVVM might be somewhat generic pattern that can, in theory, be applied in any language which uses a layered structure and a UI.
However, I’ve always found it kind of strange for anyone to try and apply it in any other technology then XAML.
Web development, in particular, has left me baffled. The first time I heared about knockout, I was like “and you think this is a good idea…why?”

luisgimx
Guest

Why not? even View.js is doing MVVM, not only Konckout.