实体框架的行级安全性

当然可以。重要的是阻止对对象上下文的直接访问（防止用户构建自己的ObjectQuery），而是为客户端提供一个更窄的网关，以便访问和更改实体。我们使用实体存储库模式来实现这一点。您可以在这篇博客文章中找到实体框架的此模式的示例实现。同样，关键是阻止对对象上下文的访问。请注意，对象上下文类是分部的。因此，您应该能够防止"未经授权"的实例化方式，即在存储库程序集之外。

然而，也有一些微妙之处需要考虑。如果您通过存储库模式在某个实体类型上实现行级视图安全性，那么您必须考虑客户端访问相同实体的其他方式。例如，通过导航关系。你可能需要将其中一些关系私有化，这可以在你的模型中实现。您还可以选择指定用于加载/保存实体的自定义查询或存储过程。存储过程往往是特定于DB服务器的，但SQL可以用通用的方式编写。

虽然我不同意实体框架不能做到这一点，但我同意"在数据库服务器上做"的评论，因为你应该深入实施防御。

添加安全性的位置实际上取决于您要保护的对象。

例如，如果你正在保护一个网站，那么在上下文级别添加过滤就足够了，因为在这种情况下，"用户"就在网站上。他们别无选择，只能浏览您的上下文，因为您将完全根据上下文编写应用程序。

在您的情况下，听起来您试图保护的"用户"是开发人员。这要困难得多。如果开发人员没有权限对数据库本身进行修改，那么您就必须将安全性放在数据库级别。再多的eSQL访问也无法绕过数据库说"不"。

根据定义，您想要实现的目标是不可能的。

如果底层数据库应用程序（SQL Server、Oracle等）没有明确地处理安全性，那么像SQL Management Studio这样的标准工具就会过时

如果应用程序的用户无法通过其他机制访问数据库，则最好由这些用户强制执行行级安全性。

我发现了一种使用Postgres和一个名为Veil的扩展的方法。它实际上是为使用Views执行所有操作（选择、更新、删除、插入）和验证WHERE子句中的权限而设计的。但Veil只是增加了有效管理内存中权限信息的数学运算，而不是每次都查询。因此，使用Veil，尽管您直接连接到DBMS，但您只能获得授予的行级访问权限。

我用面纱在某些方面修改了我的风格，例如，我开始使用Triggers而不是Views来应用权限限制。

我建议你研究这个解决方案，并尝试在这里应用它的逻辑。

即：您进行了select * from table查询，并且您得到了您想要的内容（行级发言）。