如何对将出现在 EF 中的 DbCommandTree 中的 linq 查询进行无操作更改
我有一个 linq 查询，
Context.Set<Entity>().where(x=>x.condition == true).select(x=> new ViewModel{Property = x.Property});
我希望能够通过类似的方法对 linq 查询进行更改，
Context.Set<Entity>().ChangeLinqQuery("String").where(x=>x.condition == true).select(x=> new ViewModel{Property = x.Property});
这样当我在 EFProviderWrapper 中捕获 DbCommandTree 时，我将能够发现更改并捕获字符串。我还希望确保该表达式应用于对实体的特定引用，这样，如果我将实体本身加入到实体中，它仍然能够知道对实体的特定引用是我要更改的引用。
我们的目标是能够更改 EF 生成的 SQL，因此如果您有更好的方法来实现此目标，请随时提供。
I have a linq query
Context.Set<Entity>().where(x=>x.condition == true).select(x=> new ViewModel{Property = x.Property});
I would like to be able to make a change to the linq query through something like this
Context.Set<Entity>().ChangeLinqQuery("String").where(x=>x.condition == true).select(x=> new ViewModel{Property = x.Property});
So that when I capture the DbCommandTree in my EFProviderWrapper I will be able to spot the change and capture the String. I also wish to be sure that the expression is applied to that particular reference to the Entity so that if I join the Entity on itself it will still be able to tell that that particular reference to Entity is the one I mean to alter.
The goal is to be able to alter the SQL generated by EF, so if you have a better means of achieving this goal please feel free to provide it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这是不可能的。您的
ChangeLinqQuery必须将一些自定义表达式添加到后面创建的表达式树中。问题是这个表达式树被转换为 ESQL - 这就是DbCommandTree所描述的（它不是 SQL）。据我所知，ESQL 不可扩展，因此您无法向此过程添加任何自定义表达式。即使您可以，也很可能意味着您必须重写大部分 SQL 生成以满足您的需求 = 不开发提供程序包装器，而是开发提供程序本身。使用 EF 的最佳选择是简单地替换生成的 SQL 中的表名，这将是复杂、缓慢的，除非您按照其语法构建强大的 SQL 解析器，否则也容易出错。
您最好的选择就是不使用 EF，正如我在上一个问题中建议的那样。
I don't think this is possible. Your
ChangeLinqQuerywill have to add some custom expression into expression tree created on behind. The problem is that this expression tree is translated to ESQL - that is whatDbCommandTreedescribes (it is not SQL). As I know ESQL is not extensible and so you cannot add any custom expressions to this process. Even if you could it would also most probably mean that you will have to rewrite much of SQL generation to satisfy your needs = not developing provider wrapper but provider itself.Your best choice with EF is simply replace table names in generated SQL which will be complex, slow and unless you build strong SQL parser following its syntax it will also be error prone.
Your best choice is simply not using EF as I already recommended in your previous question.