A Better Way to Deal with Complex Bindings in XAML

[@SirBenJamin_]

I hate converters, I only really use the visibility ones. The people I work with will go out of their way to write really specific converters JUST so they don't have to "pollute" their viewmodel. So we have a library of these wacky converters with really long names. For me, I think its daft. A viewmodel is specifically there to sit between the model and the View to make binding easier! .. so I will have all sorts of stuff on that sucker. Its much easier to code, debug and maintain ... and it performs better.

[@SingletonSean]

Totally agree!! The worst is when you run into a converter that references and casts some sort of domain object or view model 😬

[@TheTigerus]

you can also use Switch Case and return something like -1, 0, 1 (or enum, or w/e) saving you 2 properties to update

[@SingletonSean]

True! I'd prefer to use an enum with that approach, but then writing data triggers against enum values is kinda funky cause you have to import the enum into XAML

[@dasfahrer8187]

Clever. Bravo. 👏

[@solvedplus858]

many thanks for your awesome tutorial i hope to use in your tutorial the native MVVM without any plugins, this will be more easy for the beginners to follow

[@billymartin6497]

Wouldn't it be cleaner to have a number to color converter? Also, is there any way to have a converter to return a tuple? If so, how do I write the xaml to know which tuple value to use?

[@SingletonSean]

That would work but I like to stay away from converters if I can. In this context, the ranges that classify the colors as good, medium, or bad could be considered domain logic. I consider converters to be part of the view layer. I like to keep domain logic at the view model layer or above, preferably in the model layer.

[@billymartin6497]

@@SingletonSean Thanks for your speedy reply. Is the tuple converter possible?

[@ivandrofly]

Thanks InstanceSean :)

[@haroldpepete]

nice approach and the view looks cleaner, that would be a good video, when muldidatatrigger is worth it, use cases and more tips in your style? i mean "the clever style"

[@SingletonSean]

Thanks! I'd almost always prefer using this view model approach instead of a multi data-trigger. A good use case for multi data-triggers is, of course, when you don't have a view model. An example of this would be custom components or styling, such as only applying a style to a list view item when it's not selected and being hovered.

[@mehdi_aghaei_]

Is there any way that we could just use one function which set the rate?

[@SingletonSean]

Probably! As for this demo, a single property that could return a good, medium, or bad enum would also work. However, sometimes I don't like working with enums in XAML.

[@paulgarcia-r6b]

An interesting library you can use is DXBinding. You can write C# code in XAML itself

[@hellfim]

Wouldn't it be actually better and cleaner to handle this stuff in code-behind?

[@lexpsd]

agree, i would probably create a private method that returns a SolidColorBrush and a string, then use properties to transfer those values into xaml; long xaml is the worst nightmare if you forget about it for a week, and then will try to acknowledge it once again

[@SirBenJamin_]

@@hellfim this assumes you have a code behind file.

[@burger_flipper]

In this example it's using MVVM so code behind is absolutely forbidden

[@lexpsd]

@@SirBenJamin_ no bro, i mean in the viewmodel file

[@hellfim]

@@burger_flipper code-beind is not forbidden in MVVM. It's forbidden to put business logic there, but I believe using it for complex visual behaviours is actually OK.

[@ChadMerlin-d8m]

O'Reilly Extension

[@ConradCeleste-t6z]

Westley Drive

[@LouiseHugh-c6s]

Pollich Points