使用PRISM/Unity+EF开发MVVM应用：SaveChanges()无法更新集合项属性

看起来你遇到的这个问题在MVVM+PRISM/Unity+EF的组合场景里挺常见的，尤其是集合实体的属性更新不生效、保存后值回滚的情况，结合你提到的SQL探查器看到用旧值执行UPDATE，大概率和DbContext生命周期、实体跟踪状态这两个核心点有关，我给你拆解几个排查和解决方向：

1. 优先检查DbContext的注入生命周期 #

因为你用PRISM/Unity做依赖注入，最容易踩的坑就是DbContext被注册成了单例（Singleton）。EF的DbContext本身是设计成短生命周期的，单例模式下上下文会一直持有旧的实体缓存，不管你怎么修改属性，SaveChanges的时候都会用缓存里的旧值去更新，而且保存后上下文的缓存没更新，自然值又变回旧的了。

解决办法：把DbContext的注册改成**瞬态（Transient）或者作用域内（Per Scope/Per Navigation）**的生命周期。比如在你的PRISM Bootstrapper或者Module注册代码里：

// Unity注册示例：瞬态生命周期，每次请求都创建新的DbContext
Container.RegisterType<YourDbContext>(new TransientLifetimeManager());

// 或者PRISM的PerNavigation生命周期，适合WPF导航场景
Container.RegisterType<YourDbContext>(new PerNavigationLifetimeManager());

2. 确保集合中的实体处于被跟踪状态 #

如果你的集合实体是从数据库加载后，被克隆、分离或者重新赋值过，EF就无法跟踪到属性变化，导致SaveChanges的时候识别不到修改。比如你如果做了var items = _dbContext.YourCollection.ToList();然后把items赋值给VM的ObservableCollection，之后修改的是这个List里的对象，但如果上下文已经被释放或者对象被分离，EF就不会跟踪变化。

解决办法：

• 直接使用上下文查询出来的实体实例进行修改，不要做不必要的克隆；
• 如果确实需要在VM中持有集合，确保集合中的实体是被当前DbContext跟踪的，可以通过_dbContext.Entry(item).State查看状态，如果是Detached，需要手动附加并标记修改：

var itemToUpdate = YourObservableCollection.First(i => i.Id == targetId);
// 附加到上下文并标记为已修改
_dbContext.Attach(itemToUpdate);
_dbContext.Entry(itemToUpdate).State = EntityState.Modified;
// 或者单独标记某个属性修改
_dbContext.Entry(itemToUpdate).Property(p => p.YourProperty).IsModified = true;

3. 强制触发EF的变更检测 #

有时候EF的自动变更检测可能因为某些原因（比如集合对象的属性是复杂类型、或者绑定更新没通知到上下文）没触发，这时候可以在SaveChanges前手动调用变更检测：

// 强制EF检查所有跟踪实体的变化
_dbContext.ChangeTracker.DetectChanges();
await _dbContext.SaveChangesAsync();

4. 避免直接替换整个集合 #

如果你的VM中是直接替换了整个集合（比如YourObservableCollection = new ObservableCollection<Item>(newItems);），而不是修改集合内的元素属性，EF会认为原来的集合实体被移除，新的集合是未跟踪的对象，这时候更新自然不会生效。正确的做法是修改集合内现有元素的属性，或者用Add/Remove操作维护集合，再标记状态。

快速排查步骤 #

1. 先确认DbContext的生命周期是不是单例，这个是最常见的根源；
2. 检查要修改的实体的跟踪状态（用_dbContext.Entry(item).State）；
3. 尝试手动标记实体为Modified后再SaveChanges；
4. 调用DetectChanges后再保存。

按照这个顺序排查，大概率能解决你的问题。

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