I use WPF data binding with entities that implement IDataErrorInfo interface. In general my code looks like this:
Business entity:
p
I think @Stanislav Kniazev approach is the correct one. Your comment about not adding logic to the business object is also valid. To have a clean separation of concern, how about keeping the Person in the business layer (or the data model layer), and introduce a new class PersonVm with view logic. For the VM layer I like the containment pattern more than inheritence, and at this layer I also implement INotifyPropertyChanged, which is also a property of the VM and not the data model.
public class PersonVm : IDataErrorInfo, INotifyPropertyChanged
{
private Person _person;
public PersonVm( ) {
// default constructor
_person = new Person( );
_dirty = false;
}
public PersonVm( Person p ) {
// User this constructor when you get a Person from database or network
_person = p;
_dirty = false;
}
void fire( string prop ) {
PropertyChanged( this, new PropertyChangedEventArgs( prop ) );
}
public string name {
get { return _person.name; }
set { _person.name = value; fire( "name" ); dirty = true; }
}
...
string IDataErrorInfo.this[string columnName] {
get {
if( dirty ) return _person[columnName];
}
}
}
The idea is to put the logic of each layer at the appropriate class. At the data model layer, you do validation that only concern the pure data. The the View Model layer, you add logic that concerns the View Model (as well as notificaton and other View Model logic).