具有entity framework的行级安全性
我一直在考虑如何使用entity framework实现行级安全性。 我们的想法是拥有一个数据库不可知的方法，它将提供限制来自ObjectContext的行的方法。
我的一些初步想法涉及修改EDMGEN工具创建的部分类，并提供了一些有限的支持。 用户仍然可以使用自己的eSQL语句和QueryObject来解决此问题。
我一直在寻找一种全面的解决方案，它将存在于数据库提供商之上，以便它仍然是不可知的。
当然你可以做到。 重要的是阻止直接访问对象上下文（阻止用户构建自己的ObjectQuery），而是为客户端提供一个更窄的网关，在其中访问和改变实体。 我们使用Entity Repository模式进行操作 。 您可以在此博客文章中找到entity framework的此模式的示例实现 。 同样，关键是阻止访问对象上下文。 请注意，对象上下文类是部分的。 因此，您应该能够防止“未经授权”实例化它，即在您的存储库程序集之外。
但是，需要考虑一些细微之处。 如果通过存储库模式对某个实体类型实现行级视图安全性，则必须考虑客户端可以访问相同实体的其他方法。 例如，通过导航关系。 您可能需要将某些关系设为私有，您可以在模型中执行此操作。 您还可以选择指定用于加载/保存实体的自定义查询或存储过程。 存储过程往往是特定于DB服务器的，但SQL可以以通用方式编写。
虽然我不同意entity framework无法做到这一点，但我同意“在数据库服务器上做”的评论，因为你应该深入实施防御 。
您添加安全性的地方实际上取决于您尝试防范的人。
例如，如果您要保护网站，那么在上下文级别添加过滤就足够了，因为在这种情况下，“用户”位于网站上。 他们别无选择，只能通过您的上下文，因为您将完全针对上下文编写应用程序。
在你的情况下，听起来像你试图防范的“用户”是开发人员。 这有点困难。 如果开发人员无权修改数据库本身，那么您必须将安全性置于数据库级别。 没有多少eSQL访问能够绕过数据库说“不”。
根据定义，您要实现的目标是不可能的。
如果底层数据库应用程序（SQL Server，Oracle等）没有显式处理安全性，那么像SQL Management Studio这样的标准工具就会超越它。
您可以做的最好的事情是，只有当这些用户无法通过其他机制访问数据库时，才能强制执行应用程序用户的行级安全性。
您可能会发现本文很有用：
http://msdn.microsoft.com/en-us/magazine/ff898427.aspx
“在没有引起叛变的情况下拒绝对entity framework的访问”
我找到了一种使用Postgres和一个名为Veil的扩展的方法。 它实际上（使用Views ）使用Views进行所有操作（选择，更新，删除，插入）和validationWHERE子句中的权限。 但Veil只是添加了数学，以便有效地管理内存中的权限信息，而不是每次都查询它。 因此，使用Veil，虽然您直接连接到DBMS，但您只能获得为您授予的行级访问权限。
我在某些方面用面纱修改我的风格，例如，我开始使用Triggers而不是Views来应用权限限制。
我建议你研究这个解决方案并试着在这里应用它的逻辑。
即：您select * from table查询中进行select * from table ，您就可以得到您的意图（行级别）。