MVVM As Explained by an Idiot (Yours, Truly)
-
MVVM is old news, too. Now it's MVVM-C :laugh: I'm so glad I don't do UI stuff anymore. It seems to be the discipline with the worst jargon obsession, though we're all guilty of it to some degree.
Jon McKee wrote:
the discipline with the worst jargon obsession,
I want to agree with you here. I think it's because UI is a visual thing, there's an element of fashion about it. What's in, what's out.
The difficult we do right away... ...the impossible takes slightly longer.
-
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
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). -
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:
So, it seems like MVVM is (was?) the new buzzword
Yes.
Amarnath S wrote:
Most programmers of that time said that they were doing OO, but very few understood its real meaning;
Kinda falls down here though, because it sort of implies that eventually mud that "what is the role of the ViewModel?" yields will give way to something more cohesive as it gains traction. It has been almost 20 years since WPF was released, and like I said I was already doing this even in VB6 in the 90s before without calling it that. The issue I think, is that the ViewModels roles can only ever be "clearly" defined in the most general sense - it is a data translation facility. They are muddy because they are an adapter between one type of presentation - the datacentric model - and another - the User centric View. So I don't think they'll ever really become clearly defined or even understood by people. And honestly? We'll come up with a different pattern ultimately because of it. Give it another 20 years.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Amarnath S wrote:
So, it seems like MVVM is (was?) the new buzzword
Yes.
Amarnath S wrote:
Most programmers of that time said that they were doing OO, but very few understood its real meaning;
Kinda falls down here though, because it sort of implies that eventually mud that "what is the role of the ViewModel?" yields will give way to something more cohesive as it gains traction. It has been almost 20 years since WPF was released, and like I said I was already doing this even in VB6 in the 90s before without calling it that. The issue I think, is that the ViewModels roles can only ever be "clearly" defined in the most general sense - it is a data translation facility. They are muddy because they are an adapter between one type of presentation - the datacentric model - and another - the User centric View. So I don't think they'll ever really become clearly defined or even understood by people. And honestly? We'll come up with a different pattern ultimately because of it. Give it another 20 years.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I always thought of it as having only one difference from "normal" programming in WinForms. The View contained all the code for animations and layout; other than that, its pretty self-explanatory.
-
I always thought of it as having only one difference from "normal" programming in WinForms. The View contained all the code for animations and layout; other than that, its pretty self-explanatory.
You can do it in winforms though - and it will in fact corral you into doing it that way if you try to use its databinding facilities for anything real world. You'll end up making a viewmodel. the only differences are A) You probably won't call it that B) Not all of your controls will go through it necessarily, or you may have more than one. The reason is simple. Databinding is too basic to handle real world scenarios to the 80% rule. It's not quite there, so at some point, you're going to have to "hack" or at least indirect the databind (read: Create some kind of adapter - a viewmodel)
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 do it in winforms though - and it will in fact corral you into doing it that way if you try to use its databinding facilities for anything real world. You'll end up making a viewmodel. the only differences are A) You probably won't call it that B) Not all of your controls will go through it necessarily, or you may have more than one. The reason is simple. Databinding is too basic to handle real world scenarios to the 80% rule. It's not quite there, so at some point, you're going to have to "hack" or at least indirect the databind (read: Create some kind of adapter - a viewmodel)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I always just found bindings to leave the view clear of other code; just separate the view and other code. I used to like WinForms programming. It was so simple. Until the program got massive. And you would have to scroll endlessly to find the relevant code. MVVM just seems to me to be the next logical step to separate stuff and make the organization simpler.
-
I always just found bindings to leave the view clear of other code; just separate the view and other code. I used to like WinForms programming. It was so simple. Until the program got massive. And you would have to scroll endlessly to find the relevant code. MVVM just seems to me to be the next logical step to separate stuff and make the organization simpler.
Again, you can do it in winforms, as winforms does have databinding mechanisms in it, just like VB6 did You just need to create your ViewModel object to bind to. It's just a pattern, not a technology.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Again, you can do it in winforms, as winforms does have databinding mechanisms in it, just like VB6 did You just need to create your ViewModel object to bind to. It's just a pattern, not a technology.
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:
It's just a pattern, not a technology.
Totally agree. I'm curios: Who says otherwise? :doh:
-
honey the codewitch wrote:
It's just a pattern, not a technology.
Totally agree. I'm curios: Who says otherwise? :doh:
It sounded like you were suggesting that it was new with WPF, and that you couldn't do the same thing with winforms. Not anything you said explicitly specifically, but the read I got from your comments. Guess I was mistaken.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
It sounded like you were suggesting that it was new with WPF, and that you couldn't do the same thing with winforms. Not anything you said explicitly specifically, but the read I got from your comments. Guess I was mistaken.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
It was just a trick that made some things easier; there was nothing else special about it in my mind. And you could give your designer the Xaml and tell him/her to do their thing without having the need to speak to them. Kind of :laugh:
-
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
-
Jon McKee wrote:
the discipline with the worst jargon obsession,
I want to agree with you here. I think it's because UI is a visual thing, there's an element of fashion about it. What's in, what's out.
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
What's in, what's out.
Didn't you want to mean "crap in, crap out"? :rolleyes:
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.
-
Sure, especially if you have several views of essentially the same data. But in general the viewmodel is kind of a place to shove the big ball of mud in your app. - at least the mud involved with putting data onto the screen. I'm not trying to be too critical here, as that mud will always exist in some form - it just gets shoved around depending on the technologies being employed. That mud exists because programming patterns are little more than formalized limitations in programming languages, essentially. You know that when you employ one, there's mud involved. How much, and where depends on the particular pattern and how effective it is at papering over the given language or runtime limitation. And at least putting it in the viewmodel sticks all the mud in one place.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
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:
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.
-
Sure, especially if you have several views of essentially the same data. But in general the viewmodel is kind of a place to shove the big ball of mud in your app. - at least the mud involved with putting data onto the screen. I'm not trying to be too critical here, as that mud will always exist in some form - it just gets shoved around depending on the technologies being employed. That mud exists because programming patterns are little more than formalized limitations in programming languages, essentially. You know that when you employ one, there's mud involved. How much, and where depends on the particular pattern and how effective it is at papering over the given language or runtime limitation. And at least putting it in the viewmodel sticks all the mud in one place.
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?
-
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
