我需要在 ASP.NET WebForms 应用程序中估计(并且可能稍后构建)复杂的过滤器。为了实现高交互性，过滤器必须主要基于 ASP.NET AJAX 或 jQuery。过滤器必须允许过滤具有复杂逻辑条件(和、或、大括号)和多个运算符的数据。用户必须能够保存过滤器的查询并稍后使用(加载)(服务器逻辑)。此外，关于in运算符仍然存在讨论。
应用程序应该提供一些图形过滤器构建器。我想完全控制操作数集(过滤字段)和运算符。该组件将用于应用程序中的所有过滤操作。我的问题只是如何做 UI 部分 - 构建的“查询结构”的翻译不是问题。
你有做过这样的事吗？您能否分享一些如何最好、最快地构建此类组件的经验？我是否需要开发组件，或者是否有任何现有组件至少具有部分功能并且可以扩展以提供其他功能？因为我对客户端开发经验不是很丰富，所以我不知道从头开始开发这样的组件的任务有多复杂。
另一种可能性是定义某种元查询语言，并允许用户将查询写入某些支持构建逻辑表达式的查询文本框。
我已经检查了 DevExpress 和 Telerik 工具包中的可用控件:
- 优点:可视化非常好，速度快。我们可能拥有 DevExpress 许可证。
- 缺点:与 DevExpress 网格紧密耦合。根据文档，没有可扩展性，也无法控制操作数和运算符。它使用作为网格列提供的操作数 - 我需要更多。可能无法保存和加载过滤器。
Telerik :
- 优点:不与网格耦合，它看起来像单独的控件。
- 缺点:我没有找到文档 - 我不确定可扩展性，但代码看起来像是使用了一些数据绑定(bind)控件作为操作数的来源 = 问题。我不喜欢可视化。演示确实很慢。我们没有 Telerik 许可证。
最佳答案
我建议的最重要的事情是:让你的查询生成器 UI 与你使用的网格完全分离。当您将其紧密结合时，它会迫使您做出设计和技术决策，您以后可能会后悔。 DevExpress 特别倾向于每几个版本都会发生一些重大更改，这可能会迫使您不断重构代码。他们还有一些独特的做事方式，这可能意味着你最终会通过编码来实现你想要的。
如果您的 UI 保持非常松散的耦合，您可以按照您想要的任何方式构建它，然后获取用户的输入并从中创建网格过滤器，然后将这些过滤器添加到网格中。这还意味着，如果您决定稍后交换网格，则只需更改最少的代码(如果您决定试用组件并且需要针对两个网格运行尽可能相似的代码，则此方法也很有帮助)。
个人评论 - 在对这两个组件集进行了广泛的过滤之后，我要说一件事:我们迁移到 Telerik 是有原因的。嗯，实际上有很多原因。我们并没有后悔地回头看。此外，Telerik 的人非常擅长帮助扩展并用他们的控件做一些时髦的事情，而 DevExpress 的人倾向于采取这样的态度“为什么你想扩展我们的控件？它们不是已经很完美了吗？我们赢得了一切”毕竟是开发者大会上的人气竞赛。”。在你决定选择其中之一之前，你确实需要在它们之间进行试验。祝你好运:)
关于asp.net - Web 应用程序中的复杂过滤，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3741260/