|
Wordle 965 4/6
⬛⬛⬛⬛🟨
🟩🟩🟩⬛⬛
🟩🟩🟩⬛⬛
🟩🟩🟩🟩🟩
Jeremy Falcon
|
|
|
|
|
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
|
|
|
|
|
MVVM is old news, too. Now it's MVVM-C 
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.
|
|
|
|
|
I was and professionally still am in the same boat as you, thankfully.
But my side projects have lead me to C# source generator technology (which I knew I'd pick up eventually as I absolutely love making code write code)
That led me to find use cases for it.
That led me to the UI arena.
And WinForms is basically NRND at this point.
So here I am, an embedded dev, but with a hobby, looking for something to apply it to.
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"? 
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.
|
|
|
|
|
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 class made 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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
honey the codewitch wrote: It's just a pattern, not a technology.
Totally agree. I'm curios: Who says otherwise? 
|
|
|
|
|
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
|
|
|
|
|
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 
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. 
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: 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: 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.
modified 9-Feb-24 20:58pm.
|
|
|
|
|
It's actually come in quite handy before. I've reused the viewmodel for different views.
|
|
|
|
|
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?
|
|
|
|
|
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: )
<controls:RatingControl NumberOfStars="{Binding NumberOfStars}"
Value="{Binding RatingValue}" />
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
|
|
|
|
|
I recently saw a gif "explaining" (more like a moving diagram) MVVM and something like twelve(!) alternatives like MVC and MVP 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
