通过覆盖 ObjectQuery ESQL 永久限制 EF 结果集
有谁知道如何永久限制EntityFramework的结果集?我正在谈论这样的事情 条件映射。这正是我想要实现的目标,但有一个例外:我想以编程方式执行此操作。这是因为条件值仅在创建上下文时才会传递给 EF。此外,我不希望此列从映射中消失。
我知道如何使用 EF2.0 和反射来实现这一点。我使用 CreateQuery()
方法生成我自己的 ObjectQuery
。 CreateQuery()
允许注入我自己的带有附加条件的 ESQL 查询,例如 WHERE TABLE.ClientID == value
。
EF40 的问题是不再有 ObjectQuery
,而只有 ObjectSet
,并且不使用 CreateQuery()
。我不知道如何注入我自己的 ESQL 查询。
我想限制结果集的原因是我想将客户端数据彼此分开。这种分离应该在上下文中自动完成,这样程序员就不必向每个单独的查询添加条件 .Where(x => x.ClientID == 5)
。
也许我的方法完全糟糕——但我不知道还有什么选择。
Does anyone have any idea how to limit result set of EntityFramework permanently? I'm speaking about something like this Conditional Mapping. This is exactly what I want to achieve with one exception: I want to do this programmatically. That's because condition value will be passed to EF only on context creation. Beside I don't want this column to disappear from mapping.
I know how to achieve this with EF2.0 and reflection. I was using CreateQuery()
method to generate my own ObjectQuery
. CreateQuery()
allows to inject my own ESQL query with additional condition e.g. WHERE TABLE.ClientID == value
.
Problem with EF40 is that there is no more ObjectQuery
but only ObjectSet
and CreateQuery()
is not used. I have no idea how to inject my own ESQL query.
The reason why I want to limit result sets is that I want to separate clients data from each other. This separation should be done automatically inside context so that programmers will not have to add condition .Where(x => x.ClientID == 5)
to each individual query.
Maybe my approach is completely bad — but I don't know any alternative.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你不需要为此反思。您可以简单地使用从 ObjectContext 继承的类,或者创建 UnitOfWork 和 Repositories 的自定义实现,这将以更好的方式包装此功能(上层只能访问不公开 EF 上下文的 UnitOfWork 和 Repositories)。
对象上下文的简单示例:
You don't need reflection for this. You can simply use class inherited from ObjectContext or create custom implementation of UnitOfWork and Repositories which will wrap this functionality in better way (upper layer has access only to UnitOfWork and Repositories which do not expose EF context).
Simple example of object context: