Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have the requirement that users should be able to specify filter conditions for one kind of entity through a GUI on a thin client. These conditions must be

  • convenient to generate, meaning the GUI should guide users as much as possible. They shouldn't have to write SQL or anything.
  • stored with a time stamp, a user ID, a description, and whatnot...
  • loaded and edited
  • reusable by other users
  • used for loading matching entities from the DB via an ORM framework. Ideally I could generate a predicate out of them - SQL or maybe an Expression, which the ORM can translate to SQL

In my case users specify a condition for customers, for who invoices should be generated. There will be many different such "customer selections".

I think the specification pattern might be a good match, but couldn't find any examples, where specifications are built through a GUI, serialized and stored/reloaded/edited via an app server and used to retrieve matching entities.

Am I maybe overlooking the standard way to do such a thing? Colleagues have suggested to just build the SQL WHERE predicate on client side, but I don't like that. The client shouldn't know that much about persistence (column names...), and should only be allowed to use certain predicates, but not others. Also I'd have to parse these strings into separate predicates when I reload a condition to display them in a user friendly way.

share|improve this question
I would go with what your Colleagues say. Keep it simple. Focus on enhancing the ad-hoc result performance instead. – NoChance Aug 21 '12 at 22:47
So you wouldn't agree, that building SQL on client side only seems simple in the short run? Apart from the fact that our DBAs would probably lynch me, I'd still have to parse the SQL into some kind of simplified expression tree to present it in the GUI. I agree, that this would simplify serialization and persistence. – EagleBeak Aug 22 '12 at 7:57
You can create a good GUI, populate an object of some sort to capture user choices, pass the object down to the server and transform it to the corresponding SQL (Where, Group, etc.). I think this is the way to go! – NoChance Aug 22 '12 at 9:01
At this point I only need WHERE. What I'm struggling with is to come up with an idea for such a simple object. It would have to represent an expression tree in order to allow for flexible expressions and not just chains of ANDs or the like. Also it should limit client developers to options, which are supported by the server. I don't want somebody to provide a filter on an unindexed column, for example. – EagleBeak Aug 22 '12 at 9:36
It is valid to filter if you have at least 1 indexed column in the where clause. – NoChance Aug 22 '12 at 10:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.