|
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
|
|
|
|
|
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
|
|
|
|
|
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.
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
|
|
|
|
|
I just love it when Visual Studio displays and error that neither Microsoft nor google search returns a match for.
I'm creating an Azure function app in VS 2022 with the target framework set to .NET8.0. Building the code returns only one error: "TargetFramework is invalid. Change the TargetFramework to net5.0 or net6.0"
So VS 2022 which allows me to select net8.0 doesn't really support net8.0? (sigh)
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do. - Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
|
Yes, we are using the isolated-worker model and I thought we had everything we need, but that gives me something to check. Thank you!
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do. - Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
of course, developers would have to debug it. Hey, I have an idea. Maybe Microsoft should follow a basic UI principle. If it won't work or is not supported, don't let the user select it. The alternative might be to point out the issue with more details. But nah, I don't expect that of Microsoft.
Jeesh.
fwiw, this crap seems to be culturally embedded within Microsoft. COM, COM+, DCOM, ActiveX (another variant of COM), etc. They never learn; however, they can embed advertisements in my toolbar.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Same for C++ apparently, my colleague complained that .NET 8 could not be selected yet, so now our solution with C# and C++ projects has an ugly mix of windows8-net8 and windows8-net7 paths.
|
|
|
|
|
The first versions of 2022 didn't support net8, but I assume your colleague has a version that does. Unlike your colleague I can select net8, everything in the solution is net8.
TGIF
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do. - Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|