如何确保EF Core实体编辑状态可通知及子项状态处理

这个问题确实是WPF + EF场景下很常见的痛点——既要跟踪主实体的编辑状态，又要处理子集合的状态联动，还要纠结MVVM的边界问题。我来拆解一下你的疑问，聊聊每个方案的优劣势，再给点实际的建议：

这个问题核心是状态的归属，两种选择各有适用场景：

放在Model（你的当前实现） #

• 👍 优点：
  • 状态和实体强绑定，不管这个Invoice在哪个ViewModel里使用，编辑状态都是一致的，不会出现“同一个实体在不同UI里状态不同”的问题；
  • 像你写的PropertySet方法一样，状态逻辑可以和属性修改逻辑集中在一起，不用在ViewModel里重复写监听；
  • 跨层可用——不止UI层，业务逻辑层甚至数据层也能判断实体是否被修改，比如保存前做校验。
• 👎 缺点：
  • 违反了部分MVVM purist的“Model只存数据，不存UI相关状态”的原则（不过严格来说，IsEdited是实体的修改状态，不算纯UI状态，这点见仁见智）；
  • 如果你的Model是EF实体，[NotMapped]的IsEdited不会被持久化，这点没问题，但如果后续要序列化Model（比如传给API），这个属性会被带过去，可能不是你想要的；
  • 子项的状态联动需要额外处理，也就是你现在头疼的问题。

放在ViewModel #

• 👍 优点：
  • 严格符合MVVM的关注点分离，Model保持纯净，只负责承载数据和业务规则；
  • ViewModel可以灵活组合状态逻辑，比如结合UI的其他状态（比如“是否正在保存”）来控制按钮可用性。
• 👎 缺点：
  • 子项状态跟踪会变得非常繁琐——你需要给每个InvoiceRow写对应的ViewModel，监听每个子ViewModel的状态变化，还要处理子项的新增、删除，最后汇总到父ViewModel的IsEdited；
  • 如果同一个Model被多个ViewModel引用，状态会分散，需要额外做同步逻辑。

你提到的几个方案，以及一些补充方案，我都给你拆解下：

方案1：子项向主实体发送通知 #

实现思路 #

给InvoiceRow也加上类似的PropertySet方法，或者让它实现INotifyPropertyChanged，然后在Invoice里订阅每个子项的PropertyChanged事件，一旦子项的属性被修改，就把Invoice的IsEdited设为true；如果是新增/删除子项，在操作Rows集合时也手动更新IsEdited。

优劣势 #

• 👍 优点：
  • 状态逻辑完全在Model层闭环，ViewModel只需要监听Invoice的IsEdited就能更新UI，逻辑简单；
  • 不需要额外的ViewModel层，减少代码量。
• 👎 缺点：
  • 实体间产生耦合：InvoiceRow需要和Invoice建立关联（比如持有父实体引用，或者通过事件传递），EF实体的话要注意双向引用的配置，防止序列化/EF加载出问题；
  • 批量修改子项时，会多次触发IsEdited的设置（不过因为是bool值，设为true后再设也不影响，只是有点冗余）；
  • 如果子项是从外部传入的（比如API返回的DTO转换的），需要手动给子项绑定父实体的事件，容易遗漏。

方案2：利用DbContext的ChangeTracker集中管理 #

实现思路 #

EF的DbContext.ChangeTracker本身就会跟踪所有实体的状态（Added/Modified/Deleted/Unchanged），你可以通过它来判断整个Invoice及其子项是否有修改：

// 判断Invoice或其子项是否有修改
bool isEdited = dbContext.ChangeTracker.Entries<Invoice>()
    .Any(e => e.State != EntityState.Unchanged)
    || dbContext.ChangeTracker.Entries<InvoiceRow>()
        .Any(e => e.State != EntityState.Unchanged && e.Entity.InvoiceId == invoice.Id);

优劣势 #

• 👍 优点：
  • 完全不需要自己写状态跟踪逻辑，复用EF的原生能力，省掉大量代码；
  • Model保持纯净，不需要加任何额外的IsEdited属性；
  • 自动处理子项的增删改状态，不需要手动监听集合变化。
• 👎 缺点：
  • 依赖DbContext的存在——如果你的Invoice是离线的（比如从API获取的DTO，没有附加到DbContext），ChangeTracker就跟踪不到；
  • 逻辑和EF绑定，如果后续换ORM或者数据存储方式，需要重构；
  • 只能判断“当前值是否和原始值不同”，如果用户修改后又改回原始值，ChangeTracker会把状态改回Unchanged，而你的需求如果是“只要编辑过就算修改”（即使改回去），这个方案就不适用。

方案3：分层ViewModel方案 #

实现思路 #

创建InvoiceViewModel和InvoiceRowViewModel：

• InvoiceRowViewModel包含对应的属性和自己的IsEdited，实现INotifyPropertyChanged；
• InvoiceViewModel持有ObservableCollection<InvoiceRowViewModel>，监听每个子ViewModel的PropertyChanged事件，同时监听自己的属性变化，汇总出总的IsEdited；
• 子项的新增、删除操作都在InvoiceViewModel里处理，同时更新状态。

优劣势 #

• 👍 优点：
  • 严格遵循MVVM规范，Model完全和UI逻辑解耦；
  • 可以精细控制状态，比如区分“父实体修改”“子项修改”“新增子项”等不同场景，对应不同的UI逻辑；
  • 内存泄漏风险低（只要正确取消订阅子ViewModel的事件）。
• 👎 缺点：
  • 代码量陡增，需要写两个ViewModel，还要处理Model和ViewModel之间的转换；
  • 如果有多个地方使用Invoice，可能需要重复写ViewModel的逻辑，或者抽象基类；
  • 子项的状态汇总逻辑比较繁琐，比如要处理子ViewModel的新增、删除时的事件订阅/取消订阅。

如果不想把IsEdited放在Model，也不想写复杂的分层ViewModel，可以让ViewModel监听Model的变化：

1. 让Invoice实现INotifyPropertyChanged，Rows用ObservableCollection<InvoiceRow>；
2. InvoiceRow也实现INotifyPropertyChanged；
3. 在ViewModel里监听Invoice的PropertyChanged事件，同时监听Rows的CollectionChanged事件，以及每个InvoiceRow的PropertyChanged事件；
4. 只要任何一个事件触发，就把ViewModel的IsEdited设为true。

这个方案的优点是Model保持纯净（不用加IsEdited），ViewModel也不用写子ViewModel，缺点是ViewModel的监听逻辑会比较复杂，而且要注意在Model更换时取消之前的订阅，防止内存泄漏。

• 如果是EF本地数据编辑，且需求是“当前值和原始值不同就算修改”：优先选方案2（ChangeTracker），省心又省力；
• 如果是离线编辑，或者需求是“只要编辑过就算修改（即使改回去）”：可以选方案1（子项通知主实体），或者把IsEdited放在Model里，结合事件联动；
• 如果团队严格遵循MVVM规范，且项目复杂度较高：选方案3（分层ViewModel），虽然前期代码多，但后期维护更清晰；
• 如果只是简单场景，不想太复杂：可以试试补充的中间方案，ViewModel监听Model的所有变化来判断状态。

内容的提问来源于stack exchange，提问作者AgostinoX