IDataErrorInfo и INotifyPropertyChanged

Question

Я учусь NHibernate и MVVM и наткнулся на следующую проблему:

После того, как модель классов по NHibernate должны быть POCO объекты, есть еще один способ реализации IDataErrorInfo и INotifyPropertyChanged на модели классов?

Например:

public class Person 
{ 
public virtual int ID { get; set; } 
public virtual string firstName { get; set; } 
public virtual string lastName { get; set; } 
public virtual string phoneNumber{ get; set; } 
//... 
//implementation of equals and hash 
//... 
} 

INotifyPropertyChanged реализация

public class Person : INotifyPropertyChanged 
{ 
public virtual int ID { get; set; } 
public virtual string firstName { get; set; } 
public virtual string lastName { get; set; } 
public virtual string phoneNumber{ get; set; } 

public virtual string FirstName 
    { 
     get { return firstName; } 
     set 
     { 
      firstName = value; 
      RaisePropertyChanged("FirstName"); 
     } 
    } 

public virtual string LastName 
    { 
     get{ return lastName; } 
     set 
     { 
      lastName = value; 
      RaisePropertyChanged("LastName"); 
     } 
    } 

    public virtual string PhoneNumber 
    { 
     get { return phoneNumber;} 
     set 
     { 
      phone = value; 
      RaisePropertyChanged("Phone"); 
     } 
    } 

} 
#region INofityPropertyChanged members 
public virtual event PropertyChangedEventHandler PropertyChanged; 

public virtual void RaisePropertyChanged(string PropertyName) 
{ 
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(PropertyName)); 
} 
#endregion 

Обратите внимание, что INotifyPropertyChanged (или другой интерфейс, как IDataErrorInfo) код не относится к домену.

Вопрос в том, что с точки зрения хорошего моделирования это приемлемо? Должен ли я реализовывать эти интерфейсы на моем ViewModel?

Answer 1

См. https://en.wikipedia.org/wiki/Plain_Old_CLR_Object Я думаю, что ключевым моментом является то, что термин POCO происходит от мира Java ORM, где ваши сущности первоначально должны были наследовать базовый класс фреймворка, что привело к множеству функциональных возможностей, которые сделали класс громоздким для использования вне это рамки. Насколько я понимаю, поскольку упомянутые вами интерфейсы не имеют отношения к ORM, поэтому можно утверждать, что объект по-прежнему остается POCO в отношении ORM. А также это интерфейсы, а не базовые классы, поэтому вы контролируете всю логику.

Поэтому я не думаю, что вы обязательно должны избегать этих интерфейсов в объектах, основанных на некотором нарушении теоретического правила.

С другой стороны, это не отвечает на вопрос, является ли это хорошей идеей или нет. У меня никогда не было таких интерфейсов, но я пишу в основном многоуровневые веб-приложения, где они менее полезны. Часто случается, что представление не соответствует единому объекту - вместо этого модель представления полезна для агрегирования информации из нескольких объектов, а затем передает ее в представление.

Хотя сами интерфейсы довольно простые, они используются связыванием данных, что означает, что они должны быть на классах, используемых для привязки данных, чтобы быть полезными.

Мое предложение состоит в том, что оно сводится к следующему: реализуйте их на классах, которые вы используете для привязки данных, при условии, что это можно сделать, не вызывая проблем ни для чего другого.