如何从字符串创建 LINQ 查询?
我是 LINQ 新手,确实需要一些编码方面的帮助。
目前,我有一个字符串和一个 var 变量。
string temp = "from product in myEntities.Products where product.Name.Contains(_Name) select product";
var _Products = temp;
LvProducts.DataSource = _Products;
LvProducts.DataBind();
基本上,我想要做的是能够通过预先将其分配到字符串中来创建自定义/复杂的 LINQ 查询。完成编写后,我将字符串分配给 var 变量。然而,这显然是行不通的。因此,有人可以帮助我吗?
I am new at LINQ and really need a help with some coding.
At the moment, I have a string and a var variables.
string temp = "from product in myEntities.Products where product.Name.Contains(_Name) select product";
var _Products = temp;
LvProducts.DataSource = _Products;
LvProducts.DataBind();
Basically, what I want to do is to be able to create a custom/complicated LINQ query by assigning it into a string beforehand. After done with composing, I assign the string into the var variable. However, this is obviously will not work. Therefore, can anyone assist me on this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
您有几个选择:
使用动态 Linq
构建查询的库
苍蝇。最佳获得地点
开始是通过阅读 ScottGu 的博客
条目。然而,我不认为
这些库支持包含
你的例子中的方法。 这里是
解释如何添加的博客文章
直接执行SQL语句。查看 Linq to Sql 或 实体链接。
使用Linq 的可组合行为。这可能不是最优雅的解决方案,但如果您没有太多选择,它会非常有效。您可以将查询分为多个部分。
You have a few options:
Use the the Dynamic Linq
libraries to construct you queries on
the fly. The best place to get
started is by reading ScottGu's blog
entry. However, I don't think
these libraries support the contains
method in your example. Here is
a blog post explaining how to add
this support.
Directly execute SQL statements. Check out the MSDN docs for Linq to Sql or Linq to Entities.
Use Linq's composable behaviour. This might not be the most elegant solution but it works really well if you do not have too many options. You can just construct your query in multiple parts.
您可以通过使用 CodeDomProvider 在某些 c# 中编译此 Linq 来实现此目的 - 将脚本功能添加到 . NET 应用程序 - 但这是一个相当重量级的解决方案。如果您想了解有关如何执行此操作的更多信息,请查看 LinqPad - http://www.linqpad.net - 作者邀请您使用反编译器来看看它是如何工作的!
如果要求只是简单的 where 子句,那么替代方案可能是使用 Dynamic Linq - 请参阅 Scott Gu 的帖子和 Microsoft 的示例代码 - http://weblogs.asp.net/scottgu/archive/2008 /01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
You can do this by compiling this Linq within some c# using the CodeDomProvider - Adding scripting functionality to .NET applications - but this is quite heavyweight as a solution. If you want to see more about how to do this, then take a look at LinqPad - http://www.linqpad.net - the author invites you to use the decompiler to see how it works!
If the requirement is just down to simple where clauses than an alternative might be to use Dynamic Linq - see Scott Gu's posts and the sample code from Microsoft - http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
也许这可以帮助你
http://nlinq.codeplex.com/
BR。
Maybe this can help you
http://nlinq.codeplex.com/
BR.
首先使用 LINQ 的大部分原因是为了获得经过编译器验证的查询,这将在编译时检测错误。这将达不到这个目的,因为字符串将在运行时被解析。
为了满足您的需求,您有两种选择:
1) 进行 eSQL 查询并在 ObjectContext 上运行它。使用此功能,您仍然可以使用 myEntities.Products 等实体,并返回产品列表。
2) 使用普通的 SQL 查询,并使用 ObjectContext 直接向底层数据库调用该查询。
Much of the reason you use LINQ in the first place is to get compiler-verified queries, that wil ldetect errors at compile time. This will defeat that purpose since the string will be parsed at runtime.
For your needs you have two options:
1) Making a eSQL query and running it on the ObjectContext. Using this, you can still use your entities like myEntities.Products, and return a list of products.
2) Using a normal SQL query, and use the ObjectContext to call that directly towards the underlying database.
我的猜测是您将不得不使用动态代码执行。有关更多详细信息,请参阅 Ricks 在 west-wind 上的帖子。
My guess is that you will have to use dynamic code execution. For further details, have a look at Ricks post on west-wind.
您可以将其视为动态 SQL,将语句创建为字符串并将其解析为 SQL 语句。
既然您已经在代码中,为什么不直接在其中编写语句呢?如果使用 Lambda 而不是传统的 linq,会容易很多。我的2美分。
you're thinking of it like a Dynamic SQL where you create the statement as string and parse it as a SQL statement.
Since you're already in the code, why not make the statements right in there. It would be a lot easier if you use Lambda instead of the traditional linq. my 2 cents.