Chris Winters doesn't like object-oriented query APIs. Since Hibernate emphasizes the query /language/ approach, I'm not the best person to disagree with him here. Criteria queries are usually noisier, no doubt about that. And the query languages I've seen tend to be more expressive. Writing arithmetic and even logical expressions is a breeze in a query lanugage, but certainly not in an object-oriented Criteria API.
However, there are a couple of advantages of the Criteria approach. First, some folks like the fact that more can be done to validate the query at compile time. This is no big deal to me because I'm very unit test oriented. Much more importantly, object-oriented query APIs are much better for building queries programmatically. String manipulations suck! Getting your parentheses and whitespace right for all combinations of criteria is a pain. I've seen some truly ugly code that builds HQL strings and it could be rewritten /much/ more neatly using the Criteria API.
Especially, the new query by example stuff could potentially reduce 20 lines of code that builds a query containing the needed properties of Person to:
session.createCriteria(Person.class)
.add( Example.create(elvis) )
.list();
Well, I suppose query by example is a bit of an extreme case, and you could perhaps implement a similar feature in a query language.
Finally, object oriented query APIs can be more user-extensible. This is what I like best.
P.S. The code example Chris gives is a bit unfair to object APIs. Hibernate's Criteria API is much less verbose than that, partly due to the support for method chaining (which is barely used in Java, so I betray the time I spent with SmallTalk).
This still doesn't address the type of project I think many people gloss over, retrofitting and being able to use existing libraries of SQL. (And with good reason, since it adds several layers of complexity to what's already a sticky discussion.) I think you had an email conversation with one of my co-workers (Joe @ Optiron) recently about using Hibernate in a large project where we've got a very mature data model and are building a Java middle tier around it.
Anyway, it's still a fruitful discussion. I went back and read what I wrote and it was a little harsher than I intended.
Anyway, one of the dimensions is Representation. That is you could use String, Algebraic datatype or Quasi Quoting. The API is equivalent to defining an Algebraic Datatype.
The pros and cons of each are well known, however its best to provide all three capabilities, you just never know what the use case may be!
Carlos
Extensibility is a nice aspect.
Here is one:
How about an extension to queries that allows to score results?
criteriaRefactorability.fuzzyFactor(10);
criteriaNoTypos.fuzzyFactor(8);
criteriaExtensibility.fuzzyFactor(6);
criteriaByExample.fuzzyFactor(7);
criteriaNoise.fuzzyFactor(10);
query.bestMatchesFirst();
One point about object queries that I have seen discussed very little so far:
A common standard for object querying could be a basis for the development of query language parsers and other tools on top.
The OOFILE query language is part of the OOFILE API that demonstrates why operator overloading can be a Very Good Thing for library authors because it lets us write expressions like
people.search (people.lastName.startsWith("Den") && people.salary > 90000);
I also use a lot of method chaining which I picked up from The Design and Evolution of C++ where it was used to illustrate how to avoid keyword arguments being needed in the c++ standard.
Hi Gavin, I am a big fan of yours.
I have a question in relation to Criteria. I don't like Criteria API if search criteria is very large. I am interested in knowing how much it is fruitful to heap i.e. how much expensive it is in terms of memory.
I will glad if you reply to my this query.
Thanks in advance.