Question

I relised I have lots of models view models with those two properties

public Visibility OkButtonVisibility
{
get{  return _OkButtonVisibility;}
set{ 
_OkButtonVisibility = value;
RaisePropertyChanged("OkButtonVisibility");
}

}

public Visibility CancelButtonVisibility
{
get{  return _CancelButtonVisibility;}
set{ 
_CancelButtonVisibility = value;
RaisePropertyChanged("CancelButtonVisibility");
}

}

I wanted to create attachable interface for them like this:

Interface IOKandCancelButtonsVM
{
 public Visibility OkButtonVisibility
{
get{  return _OkButtonVisibility;}
set{ 
_OkButtonVisibility = value;
RaisePropertyChanged("OkButtonVisibility");
}

}

public Visibility CancelButtonVisibility
{
get{  return _CancelButtonVisibility;}
set{ 
_CancelButtonVisibility = value;
RaisePropertyChanged("CancelButtonVisibility");
}

}

and have my viewmodels that use this to inherite them and another interfaces with proxy properties like this

class VM1:BaseVM,IOKandCancelButtonsVM,IOtherCommonPropertyVM
{ 

} 

but then I relaised my new interfaces don’t impliment INotifyChanged.
would it be a bad idea to haveIOKandCancelButtonsVM impliment INotifyChanged
and have VM1 explicitly impliment BaseVM?

I never dealt with class inheriting same interface twice and not sure what to do.

this is only an example less than half of the VMs use those I have a few hundred properties, many shared over dozens of screens. i need a more elegant solution than sticking all on thos into the BaseViewModel

Answer 1

You cannot have an implementation in your interface definition. This means that your IOKandCancelButtonsVM definition is incorrect.

would it be a bad idea to have IOKandCancelButtonsVM impliment BaseVM

Yes it would be a very bad idea – impossible in fact – interfaces cannot implement or extend classes.

Since you asked for opinion on how to structure your code, I will also throw this out there: remove any reference to ‘visibility’ from your viewmodel. Do not return a System.Visibility value from your viewmodel.

A viewmodel shouldn’t know anything about the view. The semantically correct way to do this is to simply return a flag from the viewmodel, and use a converter to change it to a Visibility value in the binding – there is even a ready made converter in the framework for doing this: BooleanToVisibilityConverter. Try to avoid any mention of UI related terms in your VM even if it is returning a bool – it is a good practice which leads to tighter and more disciplined code, using those names willy nilly will eventually lead to smelly code.

I have a blog post which illustrates a nice approach to property change notifications: Streamlining property notifications in MVVM.

Just to make it clear, I am advising that you get rid of any ideas you have about IOKandCancelButtonsVM interfaces, by all means include simple boolean properties on a base viewmodel that will be extended by many other viewmodels that will be bound to dialogs with OK/Cancel buttons.

To diagram this in text it would look like this:

YourBaseVm <– BaseVmUsedByDialogs <– SpecificDialogVm

(note the italicising which indicates the class is abstract)