Question

很明显，对于MMVM模型类包含哪些WPF，请阅读SO答案，很明显，在大型应用程序中，一般建议是避免在表示层之外使用NotifyPropertyChanged和INotifyCollectionChanged。

但是我将如何实际实施呢？假设我有一个Model.Student类和一个StudentService类，它们从服务层返回IList<Student>>。我的视图模型如下所示：

public class StudentViewModel : ViewModelBase
{
   private readonly ObservableCollection<Student> students;
   public StudentViewModel(IStudentService service)
   {
       students = new ObservableCollection<Student>(service.GetAllStudents());  
   }
}

我如何从单个学生那里获得DataBind属性？假设其中一个学生姓名已更改，并应反映在视图中。我是否必须将Student类转换为其他实现INotifyPropertyChanged的类（如果有集合属性，还可以实现INotifyCollectionChanged）？

如果要使（业务）模型不受演示特定细节的影响，您如何建议处理此问题？

Answer 1

来自评论：

通常，应避免在视图模型中使用业务对象，以防您的视图模型中包含业务对象，这违反了层分隔。另请参阅此帖子：ViewModels in MVC / MVVM / Seperation of layers- best practices?

此外，

您描述了从viewmodel到domain model的映射，反之亦然。为了简单起见，最好在可以执行映射的位置创建一个简单的函数（可能是静态函数）（如果您想同时使用两种方法，则最好是2）。

请注意，@ dymanoid建议使用automapper之类的库来执行此类任务。

我想指出的另一件事：您的StudentViewModel有多个Students，因此最好将该模型重命名为StudentSViewModel，并创建一个新的{ {1}}。最后一个StudentViewModel是新的，很可能将拥有学生类中所有属性的90％以上。

您将获得2个好处（是的，人们总是喜欢解决过度的工程论点）：1）您的视图模型不会暴露不必要的业务逻辑/数据，反之亦然； 2）如果有什么变化，您知道在哪里修复它，即：在模型的翻译中。它使事情“简单” ；-)

因此，基本上，答案超出了问题“我应该使用INotifyPropertyChanged” ，但解决了概念性更强的部分：”如果我设法将各层分开，是否需要实施INotifyPropertyChanged并具有商业价值吗？”

如何在Presentation层中保持INotifyPropertyChanged和INotifyCollectionChanged

1 个答案: