并发控制的基本原理
在Entity Framework Core中，并发控制是防止多个用户同时修改同一数据时产生冲突的重要机制。EF Core通过并发令牌（ConcurrencyStamp）实现乐观并发控制，这种机制允许系统检测并发冲突并在保存时抛出异常。
典型并发场景分析
考虑一个典型的产品管理系统场景：
用户A获取产品信息，包含并发令牌值"0x8890"
用户B同时获取相同产品并修改名称，导致数据库中的并发令牌更新为"0x8891"
用户A尝试提交修改时，系统应检测到并发冲突
两种实现方式的比较
直接附加实体方式
第一种实现方式直接将DTO映射为实体并附加到DbContext：
var entityToUpdate = new Product {
Id = dto.Id,
ConcurrencyStamp = dto.ConcurrencyStamp
// 其他属性...
};
DbContext.Update(entityToUpdate);
这种方式会产生以下SQL：
UPDATE Products SET Name='New'
WHERE Id=27 AND ConcurrencyStamp=0x8890
优点：能正确检测并发冲突
缺点：
会更新所有属性，即使未修改
无法区分哪些属性真正被修改
可能导致数据丢失（未包含在DTO中的属性会被覆盖）
先查询再修改方式
第二种实现方式先查询实体再修改属性：
var entityToUpdate = await DbContext.Products.FindAsync(dto.Id);
entityToUpdate.Name = dto.Name;
entityToUpdate.ConcurrencyStamp = dto.ConcurrencyStamp;
这种方式会产生以下SQL：
UPDATE Products SET Name='New'
WHERE Id=27 AND ConcurrencyStamp=0x8891
优点：
只更新真正修改的属性
保留未包含在DTO中的属性值
可以准确检测属性修改状态
缺点：无法正确检测并发冲突（使用了查询时的令牌值而非原始值）
解决方案与最佳实践
针对第二种方式的并发问题，可以采用以下解决方案：
手动设置原始值
DbContext.Entry(entityToUpdate)
.OriginalValues
.SetValues(new { ConcurrencyStamp = dto.ConcurrencyStamp });
这种方法明确告诉EF Core使用客户端提供的原始令牌值进行并发检查。
重写SaveChanges方法
更系统化的解决方案是重写SaveChanges方法，自动处理所有并发令牌：
public override async Task
{
ChangeTracker.DetectChanges();
foreach (var entry in ChangeTracker.Entries()
.Where(e => e.State == EntityState.Modified))
{
if (entry.CurrentValues.TryGetValue
{
entry.OriginalValues["ConcurrencyStamp"] = stamp;
}
}
return await base.SaveChangesAsync(ct);
}
设计思考与建议
并发令牌处理策略：EF Core默认使用原始值进行并发检查，这是为了支持应用管理的并发令牌场景
性能考量：在检测到并发令牌不匹配时，可以直接抛出异常而无需执行数据库操作
混合模式考虑：对于某些场景，可能需要同时考虑原始值和当前值进行更复杂的冲突检测
DTO设计建议：确保DTO包含所有必要字段，避免数据丢失问题
总结
EF Core的并发控制机制提供了灵活的方式来处理数据冲突。理解并发令牌的工作原理和不同实现方式的优缺点，可以帮助开发者根据具体业务场景选择最合适的实现方式。对于断开连接的实体更新场景，手动设置原始并发令牌值或重写SaveChanges方法都是有效的解决方案。