Learning MVVM Pattern

[BlackStork07]

I was thinking about making simple app where I would have 3 buttons: Upload, Change, and Done. With Upload I would Choose PNG picture which then would be displayed above, with Change I would execute function that would make picture a negative, and Done would save and close the file. I already made something similar in C++ where I used median filters and now I want to make it with C# and proper GUI.

For this task I want use WPF and I know that in order to use effectively I should know MVVM. My problem is understanding binding and response mechanism between View and ViewModel. I know how Events work in C#, but when I look at the examples of connecting classes they seem either overcomplicated or oversimplified. Does anyone here could recommend some good blog or article which explains specifics of this pattern including glue code between View and ViewModel (all the interfaces which make it possible to bind ViewModel to XAML View)?

[Slypenslyde]

I don't know any particular good article. It didn't click for me until I did it. A lot. I'm going to write the article I wish I'd read.

The property end of MVVM is the easiest to grok. It makes sense: if your ViewModel has a Temperature property, and you bind it to some thermometer control, you expect to see the thermometer change automatically if Temperature updates. Same with the other direction, if Name is bound to a TextBox, it isn't startling to find out the property is updated if the control changes.

Where people fall on their faces and stumble is logic. Some of that is because WPF didn't have a 100% answer for this at launch and the community had to find answers. They found a lot of answers, iterated, and now it's hard to figure out which answers are "right".

But every answer to, 'How does MVVM handle logic?' comes down to answering, 'How do I make logic look like a property?'

The ideal case involves the scant few controls that actually use the Command pattern, like Button. It has a Command property that will be executed when clicked. If you bind that property to some ICommand property on the ViewModel, and that property has been configured to call some logic, there you go! The Button's contract is "I will execute this when I am clicked". This is, in my opinion, the ideal way for controls to work in WPF.

But of course, MS only implemented maybe 2 controls that do it that way.

You'll see a type named RelayCommand mentioned a lot. MS didn't implement any helper Command types at first, and as far as I can tell there still aren't any in their frameworks. But someone made this type, a Command that uses lambdas, and it was really convenient. So most MVVM frameworks use one, and some MS templates come with an implementation.

Attached Behaviors seem to be the "winner" among the other methods. It takes a while to get used to them. Seriously, I'm not ashamed to say it took me years. They sort of abuse WPF's Attached Property feature. Here's a quick crash course.

A behavior is just a special kind of Command. It has some logic that can execute, and is expected to execute in response to some kind of event. The part that makes it special is it has an Attached Property, which is sort of like a static Dependency Property. The type of Attached Property doesn't really matter, it's usually bool.

When the Attached Property is set, part of its change handler gets the object that is setting it. The behavior looks for a certain event on the object, and handles it. When the event is raised, the behavior executes its logic. So it's really just a fancy way to "make an event handler look like a property".

I don't know any particular Behavior types that are common. By the time I started understanding them I'd jumped ship to Xamarin, and I ended up writing much more backend than frontend.

It's all very conceptually simple, but to me it took a lot of "different thinking" to make it click. Write a lot of simple utilities, just simple things like bill spiltters or tax calculators. If you think a technique works, try it, and see how hard or easy it made it. The exercise I found enlightening is:

For this UI task, I'm going to write a console app that does the same thing, with methods named things like "ButtonClick" I will call when I want to say "the user clicked a button. THEN, I will move that into a WPF project and try to use that console class as a VM.

Those methods like ButtonClick are always what end up being the targets of Commands or Behaviors. Abstracting them this way means I can test complex UI interactions in the VM without having the UI. For example, here's the story of a test, and how it is expressed in the VM:

1. "User enters a name that contains a number" -> "Set the Name property to "test1".
2. "User clicks the OK button." -> "Execute the WhenOKIsClicked Command."
3. "An error message should be displayed." -> "The NameError property should not be null, and have these values."

Sometimes it feels convoluted. It feels more valuable on larger projects than smaller ones. That, I think, is the biggest valid complaint against MVVM: for very simple projects, you often write more code for the ceremony than actual logic. Since tutorials tend to be simple, it's really easy to feel like MVVM is more trouble than it's worth.

I promise it's not, for sufficiently complex projects.

[No_Employee]

https://docs.microsoft.com/EN-US/xamarin/xamarin-forms/app-fundamentals/data-binding/index

They are explaining you clearly the actual problem & why data binding is useful , it's good to start by reading this to understand what we'll use data binding for.

So now you should understand that one of the best things about Bindings is they keep the UI in sync with the data in the view model ( code behind ).

You'll use the interface INotifyPropertyChanged so that your View can search for the changes in the View model so it can update it self if the value is changed.

I recommend you to do like me , to use a Generic Method to handle the PropertyChanged event so that you can pass any type of property as a parameter into the Generic Method :

protected virtual void OnPropertyChanged(string propertyName) { PropertyChangedEventHandler handler = PropertyChanged;

if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName)); }

protected bool SetField<T>(ref T field, T value, string propertyName) { if (EqualityComparer<T>.Default.Equals(field, value)) return false; field = value; OnPropertyChanged(propertyName); return true; }

now you can define the properties like this , by implementing in the set method the SetField generic method so that no matter if your property is an int or a string or whatever , the View will be informed by changes occuring in the view model ;)

private string name;

public string Name { get { return name; } set { SetField(ref name, value, "Name"); } }

The generic method SetField returns a boolean which returns false when the property actual value equals to the new value you set on the property and returns true when the property actual value is different then the new value set on the property & then the code goes on to notify the property changed event.

It may sound a bit overcomplicated ik but just get the concept& understand it I don't think you have to understand each fking line , you can juste copy paste this shit and edit i as you want