使用 Linq 表达式树设计灵活的高级搜索的模式或技术
我希望向我的 ASP.NET/SQL Server 2005 应用程序添加“高级搜索”功能。 理想情况下，我希望它是表驱动的。 例如，如果我的架构因向我要搜索的表添加新列而发生变化，我希望 UI 将新列的添加反映为可搜索字段。 我可以设想一些控制表，其中包含可搜索字段、它们的类型、关联的查找等。
构建 UI 时可以查阅这些表。 我的问题在于创建动态 SQL 的最佳方法。 一种方法是自己构建参数化 SQL 语句。 但我对 Linq 很感兴趣，不知何故，我认为 System.Linq.Dynamic 命名空间 - 和 Linq 表达式树 - 可能会提供更优雅/强大的解决方案？
希望任何此类解决方案都可以与 Linq to Sql 或 Linq to Entities 配合使用。 我调查这条路径是否正确，或者这个问题空间实际上不是表达式树的用例之一？
I'm looking to add an "advanced search" capability to my ASP.NET/SQL Server 2005 application. Ideally, I'd like it to be table driven. For example, if my schema changes with the addition of a new column to a table that I want to search, I'd like to have the UI reflect the addition of the new column as a searchable field. I can envision some control tables that contain the searchable fields, their types, associated lookups, etc.
These tables can be consulted when constructing the UI. My question lies with the best approach to create the dynamic SQL. One approach would be to construct a parameterized SQL statement myself. But I'm intrigued by Linq, and somehow I think that the System.Linq.Dynamic namespace -- and Linq Expression Trees -- might provide a more elegant/robust solution?
Hopefully any such solution would work with either Linq to Sql or Linq to Entities. Am I right to investigate this path, or are is this problem space not really one of the use cases for expression trees?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以使用表达式树，通过构建一棵树来比较架构中的所有字段，然后将该表达式传递到 Linq2Sql 以获取所需的 sql。 但为什么要麻烦呢？ 这需要更多的编程工作，代码将更难理解，并且除了理论上能够替换数据提供者之外没有任何好处。
（嘿霍华德） - 事实上 - 在这种情况下使用字符串将比使用表达式树简单得多。 另一方面，如果您要向用户提供一种小型查询语言，那么表达式树会派上用场。
You could use expression trees, by building up a tree that does a comparison of all the fields in the schema and then passing that expression into Linq2Sql to get back out the sql you want. But why bother? It's more programming effort, the code will be harder to understand, and there’s no benefit other than a theoretical ability to swap out data providers.
(Hey Howard) - indeed - working with strings in this case is going to be a lot simpler than w/ expression trees. On the other hand, if you were going to provide a small query language to your users, then expression trees would come in handy.