MVVM As Explained by an Idiot (Yours, Truly)
-
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
-
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.
