（我是根据评论者的建议从 SO 交叉发布的）
我们的 DBA 创建了一种模式，其中我们的数据库层通过视图和 CRUD 存储过程暴露给 EF。CRUD 与视图背道而驰。所有视图都有 NOLOCK 提示。据我所知，NOLOCK 是脏读，这让我很紧张。我们的数据库容量不大，但似乎一揽子 NOLOCK 在保持数据完整性的同时不是很可扩展。我知道解耦是个好主意，但问题是我们没有。我们外部暴露的对象看起来就像我们的视图一样，它们与我们的表 1 到 1 映射。
“如果我们想改变底层数据模型，我们可以。” ......但我们没有。从 VS/EF 工具的角度来看，我不会触及这一切是什么 PITA。
这种情况下用NOLOCK是不是不好？由于我们的数据库看起来与我们的类库完全一样，我认为摆脱整个视图/存储过程层并直接从 EF 访问 DB 是有意义的，是吗？
盲目使用 NOLOCK 是愚蠢的。对此根本没有最佳实践。这可以解释为完全的傲慢：有人比选择 READ COMMITTED 作为默认值的 MS 更了解
来自 SO：“在 EF4 中使用 NOLOCK 提示？” . 除了我称 DBA 为木偶之外，来自 MS EF 团队的一个人也给出了答案。和SQL - 你什么时候应该使用“with (nolock)”
此外，NOLOCK 在更新、插入、删除时被忽略。
使用 1:1 视图也很愚蠢。它没有增加任何价值。来自程序员.se “哪些流行的“最佳实践”并不总是最好的，为什么？.
使用视图来临时隐藏表更改是可以的，但是基于教条的额外层是没有意义的。而且我敢打赌你没有 WITH SCHEMABINDING 所以无论如何视图都可能与表格不同（所以）