mvvm-helpers | Collection of MVVM helper classes for any application | Model View Controller library

You could achieve this in XAML only, by using a multi-binding on the IsEnabled property on the Sign In Button to the user name and the password TextBoxes along with a custom value converter that converts the bound strings to a bool that indicates whether they are empty or not.

However, in this case that is not possible, since you should avoid using Command and IsEnabled at the same time, as it can lead to strange behavior. Commands offer a mechanism to determine, if an action is possible or not and will in turn set the IsEnabled state.

A command can indicate whether an action is possible by implementing the CanExecute method. A button can subscribe to the CanExecuteChanged event and be disabled if CanExecute returns false or be enabled if CanExecute returns true.

As you can see, setting both a Command and IsEnabled will interfere with each other. Although it might work, if you specify IsEnabled before Command in XAML, this is a brittle solution, so choose one, in this case favor Command with its built in mechanism.

The good news is that instead of doing this in XAML, you can achieve the same in your view model and save yourself some code by passing a CanExecute delegate to your LoginCommand as follows.

one way you could do is having a static class ServiceLocator, which is initialized only from the beginning. This class exposes a readonly ServiceProvider, and you can call it to get the thing you register.

You may read somewhere else, or someone else here may comment this is anti-pattern, which is generally out of context. Depending on what you are trying to do and how your solution is structured, this service locator pattern can be totally fine.

here is a sample project you can use for reference https://github.com/weitzhandler/UnoRx/tree/f2a0771e6a513863108e58ac7087078f39f7e3ed

an alternative will be, writing a viewmodel locator, which automatically resolves all dependencies through your view. This, however, may or may not overkill your use case.

finally, my personal flavor, having a shell project that depends on auto discovery and auto resolving; and each discovered smaller projects will internally depends on either service locator or function compositions