我们的应用程序通过 Web 服务公开查询，我们发现我们的客户经常需要自定义查询，要么通过指定附加条件进一步限制返回的结果，要么通过询问我们尚未提供的内容暴露。
现在，我们可以采取为每个新方法创建新方法的方法，但这有点不方便； 在客户站点部署我们的应用程序通常需要数周的分阶段集成测试。 我们提出了一种命名查询机制，应用程序管理员可以通过参数化的名称来定义查询，以及简单地调用这些参数的相应 Web 服务。 然而，我忍不住认为以前有人已经解决了这个问题，所以我希望 SO 社区就可能的设计提供一些意见。
谢谢！
更新
规范模式是一个很好的模式，但是我们的应用程序处理足够的数据，我们希望将尽可能多的查询工作推送到 RDBMS 中，这样可以更好地优化查询计划比我们想要的还要多。 此外，我们支持三个 RDBMS 后端，因此我们不得不使用最大公分母方法：我们使用功能最少的数据库可以提供的尽可能多的功能。
Our application exposes queries by way of web services, and what we've found is that our clients often want custom queries, either by way of further limiting the results returned by specifying additional criteria, or by asking for things that we don't already expose.
Now, we can take the approach of creating new methods for each of these new methods, but that's somewhat inconvenient; deployment of our application at a client site usually requires weeks of staged integration testing. We've proposed a named query mechanism, where the application administrator would define queries by name that are parameterized, and a corresponding web service that simply invokes these parameters. However, I can't help but think that someone has solved this problem before, so I'd like some input from the SO community on possible designs.
Thanks!
Updates
The specification pattern is a good one, but our application deals with enough data that we want to push as much of the querying work down into an RDBMS, which can do a better job of optimizing the query plan than we would ever want to. Moreover, we support three RDBMS backends, so we're stuck using a greatest-common-denominator approach: we use as much capability as the least functional database can provide.
发布评论
评论（3）
我还建议考虑此类应用程序中的“规范模式”作为后端的设计决策。 检查以下有关“规范模式”的帖子：
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
I would also recommend to consider the "Specification Pattern" in this type of applications as a design decision for your backend. Check the following posts about "Specification Pattern":
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
为您的用户提供的功能。
优点：
functionality for Your users.
Advantages:
由于我们确实不知道您的用户如何使用您的界面，因此就感觉更接近“囚犯正在管理庇护所”问题。
有一些非常好的建议和常见方法可以解决这个技术方面的问题，但是它们对您的用户有用吗？ 也许他们真的不在乎你的问题，而是有一个很好的一键解决方案？ （或者更像谷歌？）
Since we really don't know which how your users use your interface it seems a little premature to give a technical advice on something that feels a lot closer to "Inmates are running the Asylum" problem.
There are some very good advice and common ways to solve this i technical aspects but do they work for your users? Maybe the really don't give a crap about your problem but rather have a fine working one button solution? (Or more like google?)