MVVM PropertyChanged is not Component related!

What? I use many components!

ok - let's assume you have a Button on the Form and the button is labeled "Save". How do you want to handle this button? 

1.) You can use this button like a web designer and after the button is pressed you can show up some hints: "Password missing", "Email missing" or whatever. So the user can press <Save> and directly see what is missing.

2.) You can disable then Button and enable it if every field is filled as you expect.  This is kind of a guessing game or you must have some remarks like "*" for fields that have to be filled. The drawback is, sometimes you have to search the view for the little missing "I agree" checkbox.

In a few situations, I like (1), but in most cases, I use (2).

So how to handle this in the ViewModel?  PropertyChange('DisableButton')?

No, this is wrong.

You have a property at the ViewModel like:
Property CanSave : boolean read fCanSave write SetCanSave;

In the setter you can fire PropertyChange('CanSave') and every component that has to change something could be informed by this event. When a component got his PropertyChanged call it can ask the ViewModel.

SaveBTN.Enabled := fViewModel.CanSave;

ok. 

This is the same stupid thing, already mentioned in my last post. I know "you" can bind a button to an ICommand, but that is not my idea. My PropertyChange would also include the boolean so the component or better the binder can set the value directly. Of course any boolean field could be bound directly, but what if I must do a little bit more? 

One of many ways to handle this is a simple procedure:

Binding.Bind('CanSave',Procedure(aEvent:TPropertyChangedEvent )

  begin

    if aEvent.ParamCount = 1 then

      begin

        if aEvent.Args[0].AsBoolean

          then StateImage.Bitmap.Assign(YesIMG)

          else StateImage.Bitmap.Assign(NoIMG);

      end; 

  end);

I use this approach for everything that is not working out of the box. (Implementation is currently still under consideration in some parts)

And this is the main thing. The ViewModel knows the Model (in most cases) and the View knows the ViewModel. But the Model does not know the ViewModel and the ViewModel does not know then View. Perhaps the designer of the View is a different developer than the ViewModel.

Perhaps the Model has already two new fields and the ViewModel has only implemented one of these fields, but the View isn't changed at all. Everything should work fine because there is not 1:1 relation. What should the binder do? In debug-mode it would be nice if the binder throws an exception "Property not found" and in release mode? It depends on the settings. I like the idea that every Visual Component is set to Visible := false; if the necessary property is still missing in the ViewModel, but this is up to you. How do you handle incompatibilities between the View and the ViewModel? Feel free to leave a comment!

Now, how about the Unittests?

The Model is simple, just write your tests. Test for the View? Perhaps. But besides your most important Model-Tests you also want to test your ViewModel. 

Testing your ViewModel without a View must be possible, so your Test class slips into the role of the View. By subscribing to the 'CanSave' property change - for example - and filling all the fields (or not for the negative test), the test class can check if everything works as expected.

How can you test complicated behavior like the user interaction with a Grid?

Well, this may be the topic of one of my next blog posts about my #DMVVM framework.

So stay tuned.