IDataErrorInfo 和 INotifyPropertyChanged答案

【问题标题】：IDataErrorInfo and INotifyPropertyChangedIDataErrorInfo 和 INotifyPropertyChanged
【发布时间】：2016-06-02 20:40:28
【问题描述】：

我正在研究 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 上实现这些接口吗？

【问题讨论】：

您的问题令人困惑。你认为 POCO 是什么意思？这如何阻止您实现这些接口？您可能应该扩展您的问题以描述一个具体问题 - 目前它太宽泛了。
POCO 不是一个只包含与域有关的字段的类吗？在模型上实现这些接口时，我是否违反了这条规则？

标签： c# nhibernate mvvm

【解决方案1】：

请参阅https://en.wikipedia.org/wiki/Plain_Old_CLR_Object 我认为关键点是 POCO 术语源自 Java ORM 世界，您的实体最初必须从框架基类继承，引入了许多使该类难以使用的功能在那个框架之外。据我了解，由于您提到的接口与 ORM 无关，因此可以说该对象对于 ORM 仍然是 POCO。而且它们是接口，而不是基类，因此您可以控制所有逻辑。

因此，我认为您不必基于某些理论上的规则违规来避免实体中的这些接口。

另一方面，这并不能回答这是否是一个好主意的问题。我在那里从未有过这些接口，但我主要编写基于 Web 的多层应用程序，无论如何它们都不太有用。经常发生的情况是视图不对应于单个实体 - 相反，视图模型可用于聚合来自多个实体的信息，然后将其传递给视图。

虽然接口本身非常基本，但它们被数据绑定使用 - 这意味着它们必须在用于数据绑定的类上才有用。

我的建议是归结为：在用于数据绑定的类上实现它们，前提是可以在不引起其他任何问题的情况下完成。

【讨论】：