开发人员在重写默认行为中的责任
LINQ to SQL 不强制满足以下需求,但如果这些需求未得到满足,就会导致行为不明确。
重写方法不能调用SubmitChanges 或 Attach。 如果在重写方法中调用这些方法,LINQ to SQL 会引发异常。
重写方法不能用来启动、提交或停止事务。 SubmitChanges 操作以事务的形式执行。 内嵌的事务可能会干扰外层事务。 加载重写方法只能在它们确定 Transaction 中未在执行相应操作后启动事务。
重写方法应遵循适用的开放式并发映射。 发生开放式并发冲突时,重写方法应引发 ChangeConflictException。 LINQ to SQL 会捕获此异常,以便你可以正确处理 SubmitChanges 时提供的 SubmitChanges 选项。
Create (
Insert
) 和Update
重写方法在相应操作成功完成后应使数据库生成的列的值流回对应的对象成员。例如,如果
Order.OrderID
映射到标识列(autoincrement 主键),则InsertOrder()
重写方法必须检索数据库生成的 ID 并将Order.OrderID
成员设置为该 ID。 同样,时间戳成员必须更新为数据库生成的时间戳值,以确保更新后的对象一致。 如果未能传播数据库生成的值,则会造成数据库与 DataContext 跟踪的对象之间不一致。调用正确的动态 API 是用户的责任。 例如,在更新重写方法中,只能调用 ExecuteDynamicUpdate。 LINQ to SQL 不检测或验证调用的动态方法是否与适用的操作相匹配。 如果调用了不适用的方法(例如,为要更新的对象调用了 ExecuteDynamicDelete),则结果是不明确的。
最后,重写方法应执行明确的操作。 LINQ to SQL 操作(如紧急加载、延迟加载和 SubmitChanges)的语义要求重写提供明确的服务。 例如,只返回空集合而不检查数据库内容的加载重写有可能会造成数据不一致。