我最近一直在研究数据库解决方案，并遇到了Entity Framework。我正在使用Code First生成表，但是在尝试正确构建代码布局时，遇到了设计问题。
我倾向于遵循的通用MVVM设计是Model和ViewModel都继承INotifyProperty，因此，当绑定(bind)到模型的任何更改发生时，ViewModel可以监听。
但是，对于SQL数据库和EntityFramework。我的模型基本上都继承了DbContext，并且都是POCO对象。
因此，如果模型不再具有引发事件的方式，则 View 模型将无法再监听更改。当ViewModelA更改模型(sql数据库)中的项目时会发生什么。 ViewModelB如何知道它已更改，因此可以相应地更新？
先感谢您。
最佳答案
首先，您的“普通旧CLR对象”(POCO)不应从DbContext继承。相反，使用Entity Framework(代码优先)，您的应用程序通常将具有一个从DbContext继承的类。此类通常包含几个DbSet属性，它们是POCO的集合。
第二，即使您的POCO确实继承了某个基类，也没有理由他们也不能实现INotifyPropertyChanged。 C#不支持多重继承，但是它允许类实现接口(interface)，即使它也从基类继承。实际上，一个类可以从多个接口(interface)继承，也可以从基类继承。
考虑到这两点，没有理由您的POCO无法实现INotifyPropertyChanged。那是否真的是最好的架构是另一个问题，而答案实际上是一个很大的“取决于”。
我个人不在POCO上使用INotifyPropertyChanged。取而代之的是，我通常在 View 模型中具有响应用户操作(例如单击“提交”按钮)的命令。这些命令通常只是直接在同一 View 模型上更改某些内容，但是如果它们导致对模型的更改，它们将直接更改实体上的某些数据或委托(delegate)给处理此类事件的类(具体取决于模型的复杂性)。应用)。如果命令确实导致数据库更改，并且其他 View 模型需要了解此信息，那么我将使用Messenger(这是大多数MVVM框架的基本功能)发布一条消息，指出发生了某些更改(以及其他有用数据) ，然后让其他 View 模型注册该消息并做出相应的响应。
关于sql - MVVM和 Entity Framework -引发事件的原因是什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/36343959/