可扩展查询接口的优秀设计是什么？

Question

我们的应用程序通过Web服务公开查询，我们发现我们的客户经常需要自定义查询，通过进一步限制通过指定其他条件返回的结果，或者通过询问我们不做的事情已经曝光了。

现在，我们可以采用为每种新方法创建新方法的方法，但这有点不方便;在客户端站点部署我们的应用程序通常需要数周的分阶段集成测试。我们提出了一种命名查询机制，其中应用程序管理员将按参数化的名称定义查询，以及仅调用这些参数的相应Web服务。但是，我不禁认为有人之前已经解决了这个问题，所以我希望SO社区能够就可能的设计提出一些意见。

谢谢！

更新

规范模式很好，但是我们的应用程序处理足够的数据，我们希望将尽可能多的查询工作推送到RDBMS，这可以比我们想要的更好地优化查询计划至。此外，我们支持三个RDBMS后端，因此我们坚持使用最常见的分母方法：我们使用尽可能多的功能，因为功能最少的数据库可以提供。

Answer 1

我还建议将此类应用程序中的“规范模式”视为后端的设计决策。查看以下关于“规范模式”的帖子：

http://www.mattberther.com/2005/03/25/the-specification-pattern-a-primer/

http://devlicio.us/blogs/jeff_perrin/archive/2006/12/13/the-specification-pattern.aspx

Answer 2

• 看看Hibernates Criteria API并使用它或构建一些类似的东西 为您的用户提供的功能。
• 如果值得付出努力，请提供一个树状界面来分组标准。 （“组的所有标准必须匹配”/“一个标准必须匹配”/“否定”）

优点：

• 易于构建。
• 可以使用用户参数。
• 可以进行强有力的查询。
• 您可以应用限制，例如 SELECT ... FROM table WHERE someRestriction AND（用户提供的条件）

Answer 3

由于我们真的不知道您的用户使用您的界面的方式，因此对于感觉更接近“Inmates are running the Asylum”问题的内容提供技术建议似乎为时尚早。 有一些非常好的建议和常用方法来解决这个技术问题，但它们是否适合您的用户？也许真的没有给你一个关于你的问题的废话，而是有一个很好的工作一键解决方案？ （或者更像谷歌？）