MVVM As Explained by an Idiot (Yours, Truly)
-
I've never used MVVM. Today I realized I had to. So I started reading. It's a bunch of 10 dollar words to explain a 5 dollar concept. Microsoft, honest edition: "We originally intended you bind your business data directly to controls but when that didn't work in the real world, we noticed people would create an intermediary binding object to transform the data, and then bind to that. We formalized what y'all have been doing since VB6, and gave it a confusing name to make it our own, because you are lowly plebes."
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I recently saw a gif "explaining" (more like a moving diagram) MVVM and something like twelve(!) alternatives like MVC and MVP :wtf:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Have seen interviewers ask this question: Given a simple project, with a UI, and a simple database, how would you structure your code as per MVVM (meaning which pieces-of-code would you place in your M, VM and V parts). And have heard diverse answers; the M and V parts seem pretty straightforward, but with VM, there's lack of clarity. So, it seems like MVVM is (was?) the new buzzword (Just like OO was in the early 90s. Most programmers of that time said that they were doing OO, but very few understood its real meaning; some even thought that merely including the keyword
classmade a non-OO code as OO).Amarnath S wrote:
very few understood its real meaning
This is in essential the difference between "programming" and "SW engineering". Everybody can program, not everybody has the knowledge and skills to engineer SW.
-
Amarnath S wrote:
And have heard diverse answers; the M and V parts seem pretty straightforward, but with VM, there's lack of clarity.
If M and V are clear... for me VM would be all what doesn't fit the other two. Exclusion principe can simplify things too :rolleyes: :-D
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
That's essentially a correct assessment of the role of the ViewModel, as far as I can tell. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I think it stinks at that job. Why has there been no improvement in the connection between UI and properties? All the errors and limitations of inputs connected to the UI are so tedious to do. Is the current situation really the best we can do?
From what I can tell you need to viewmodel in order to perform two tasks. Complicated binds Binds involving transforming data. Both cannot be done at least in part due to the fundamental syntax limitations of declarative binding, to wit: How do you actually describe a data transformation in a string literal? (by that i mean, a transformative binding here: )
Therein lies a big part of the problem. What is one to do? I suppose you could expose your data models as XML and describe the binds using XSLT transforms but I can think of things I'd rather do, like stab my own eyes out.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I recently saw a gif "explaining" (more like a moving diagram) MVVM and something like twelve(!) alternatives like MVC and MVP :wtf:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Alternatives like MVC ... it depends on which rubber ruler you use, but is kind of apples and oranges because the way they solve the separation issue is so much different. Personally I think such a gif only confuses the issue. Not all diagrams are helpful.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Alternatives like MVC ... it depends on which rubber ruler you use, but is kind of apples and oranges because the way they solve the separation issue is so much different. Personally I think such a gif only confuses the issue. Not all diagrams are helpful.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
Personally I think such a gif only confuses the issue.
It did :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've never used MVVM. Today I realized I had to. So I started reading. It's a bunch of 10 dollar words to explain a 5 dollar concept. Microsoft, honest edition: "We originally intended you bind your business data directly to controls but when that didn't work in the real world, we noticed people would create an intermediary binding object to transform the data, and then bind to that. We formalized what y'all have been doing since VB6, and gave it a confusing name to make it our own, because you are lowly plebes."
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
On top of that, the MS bindings have bugs on the edge conditions. My hand rolled bindings don't.
Silly me for assuming they would have fixed those by now. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I've never used MVVM. Today I realized I had to. So I started reading. It's a bunch of 10 dollar words to explain a 5 dollar concept. Microsoft, honest edition: "We originally intended you bind your business data directly to controls but when that didn't work in the real world, we noticed people would create an intermediary binding object to transform the data, and then bind to that. We formalized what y'all have been doing since VB6, and gave it a confusing name to make it our own, because you are lowly plebes."
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
The part MVVM misses is that UWP and WPF have powerful "binding" engines; and that properties can be "functions". A POCO can be "smart", in the sense that while it has no "methods", it can contain functional programming (expanded "getters" if you will). There are no "fixed" layers as the MVVM model tries to paint.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
From what I can tell you need to viewmodel in order to perform two tasks. Complicated binds Binds involving transforming data. Both cannot be done at least in part due to the fundamental syntax limitations of declarative binding, to wit: How do you actually describe a data transformation in a string literal? (by that i mean, a transformative binding here: )
Therein lies a big part of the problem. What is one to do? I suppose you could expose your data models as XML and describe the binds using XSLT transforms but I can think of things I'd rather do, like stab my own eyes out.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
You can use the Behavior class to mess around with that. Effective but I wont say pretty; it's an attached property
-
Have seen interviewers ask this question: Given a simple project, with a UI, and a simple database, how would you structure your code as per MVVM (meaning which pieces-of-code would you place in your M, VM and V parts). And have heard diverse answers; the M and V parts seem pretty straightforward, but with VM, there's lack of clarity. So, it seems like MVVM is (was?) the new buzzword (Just like OO was in the early 90s. Most programmers of that time said that they were doing OO, but very few understood its real meaning; some even thought that merely including the keyword
classmade a non-OO code as OO).Amarnath S wrote:
Most programmers of that time said that they were doing OO, but very few understood its real meaning
I feel like this is both a buzzword problem AND a problem of fundamentals. Buzzwords are great for VC/series funding (who wants to invest in an existing solution with a simple improvement? But a new complicated sounding word? Hell yea!) but I think it does active harm to new-ish engineers because it obfuscates the fundamentals. An example I always give is microservices. Yes, I know there are millions of pages of material on the subject, but at its core it's just a service de-coupled on scaling boundaries/requirements. That simple explanation not only explains how to break-down services into microservices but also gives you an idea of where the "nanoservice" boundary lies (if you break it down into pieces that don't have independent scaling requirements, you've gone too far). But a simple, straightforward description doesn't sell books. It doesn't earn VC funding. Hence why we now have "microservices" that few people understand and implement correctly. It's similar to when SPA's like Angular became the norm. New, fancy buzzwords to obfuscate the real purpose of the technology, so now the mom and pop store that really just has a couple static pages that occasionally get updated? Now it's a dynamic, complicated mess that they have to spend 10x the money on upkeeping. All because the new hype/buzzword is SPAs. No benefit to them or their customers. I really hope someday people get back to realizing that every tool has a purpose. And using the hype-est, usually-wrong tool for the job only makes the engineer look inept, makes the business owner lose money, and makes the customer suffer. The only people that win are the buzzword charlatans that cash out and leave you high, dry, and picking up the bill. /rant I'll grab my coat now. I just /really/ have a bone to pick with buzzword charlatans. They're ruining our industry in my opinion.
