But this wouldn’t be Specifiation pattern any more, would it be? Based on the article referenced by Lars, in the center of the Specification pattern there is an object which decides whether a domain object satisfies some condition(s) or not. In what you suggest, the decision is made outside the Specification, so I am not sure if this is still the same pattern. (I assume that by “Criteria object”, you mean a QueryDefinition object.)

I think I actually prefer them over having an extra (defaulted) argument that specifies the fetch strategy. That smells too much like the Flag Argument I’ve learned to abhor since reading Clean Code and Implementation Patterns.

In fact since reading those books I’ve moved towards writing more shorter focused methods with descriptive (and therefore somtimes long) names instead of writing “clever” methods that can do all kinds of stuff when passed the right arguments. I guess that is why I’m not too enthusiastic about Lars’ criteria/specification suggestion.

In the app we’re building we know up front the kind of queries we want to do (no search forms), so having findByXXX methods make sense. They are lot more expressive than having the client build some kind of specification object. Be it JPA Criteria or your own class.

On the other hand if your app needs to support all kinds of ad hoc queries, such a mechanism makes sense.

When we were last faced with this problem, we also decided against findOrdersWithThisAndNotThat-type methods. In fact, we regarded them as violations of the DAO pattern (@Vincent: I’m curious as to what your thoughts on this are).

In our opinion, a DAO should be tailored to retrieve the information that the application needs, with different methods for different needs. But from a domain model perspective, findOrdersWithThisAndThat and findOrdersWithThisButNotThat return the same information: a collection of Orders meeting some criteria.

The WithThis… bit thus does not identify a different business need, it is simply a “hint” that only a certain part of the returned object graph is required, and that the rest may be ignored. The usual assumption being that this will lead to a performance improvement.

But assume that, for some specific implementation, findWithThisButNotThat is actually slower/more memory intensive/more insert favourite performance metric here than findWithThisAndThat. Would it ever be called?

Our approach was to (attempt to) model what we felt the WithThisAndThat actually represents: a suggestion to the implementation that only certain properties are required, and others may be ignored if this is likely to improve performance. We called it a FetchModel and allowed the user to specify FetchTypes (very similar to Hibernate’s FetchModels) for properties.

For those DAO methods for which this was relevant, we then had an overloaded method (let’s defer the discussion about the evils of overloading for a minute)

  /** Uses the default fetch model */
  Collection findOrdersSubmittedSince(Date date);

  Collection findOrdersSubmittedSince(Date date, FetchModel fetchModel);

where, in the case of your example, you would specify something like

  FetchModel noOrderLinesFetchModel = new FetchModel(Order.class);
  noOrderLinesFetchModel.setFetchType("orderLines", FetchType.NONE);

It’s then down to the implementation to interpret the fetch model, if desired.

Writing the code to actually implement a fetch model specification for a specific ORM framework is non-trivial, but if done with a bit of thought it can easily be reused.

I think that depends a little bit on whether you regard the use of a particular Criteria API as an “implementation detail”.

If, for whatever reason, you do decide to add a “generic” find(Criteria) method to your DAO, you’ll need to use some kind of Criteria objects. Should you have to reinvent this particular wheel if a suitable implementation already exists?

To be clear: this is only a question of perspective. If you decide to use the JPA Criteria in your DAO interface definition, you will still force clients to have a dependency on (that part of) JPA, which is something you may want/have to avoid.

But I think it’s perfectly valid to interpret your interface’s definition of find as “the client can specify a set of filter criteria, and it is the job of the DAO implementation to interpret these and return the correct results”. And then, at least according to me, it’s not implementation leakage.

In practice, of course, it may be difficult to use a certain Criteria API in any implementation other than the “native” one.
Indeed, in previous projects I have ended up reinventing some of this wheel and writing my own Criteria API, together with a converter that converted “my” criteria to Hibernate criteria, for use in a Hibernate implementation.
In this case, the reasons were, in fact, less related to enforced Hibernate dependencies. Instead, the key considerations were to

• use only criteria objects that could be easily and cheaply serialized and constructed in other programming languages and
• limit the expressiveness of the critiera API up front (i.e. on the client side), rather than returning CriteriaNotSupported-type errors later. We didn’t want to allow “A or B”, for instance, only “A and B”.

No need to apologise, I am glad you answered your own question .

LOL…serves me right for posting *before* actually reading the chapter on Specifications in Evan’s DDD book. Turns out that implementing a Specification to return a Criteria object (or SQL string, if you like) to be executed by your domain Repository is perfectly valid, and gets around having to ship your objects across the wire to filter them. So Specs really do mesh well with Repositories (which is explicitly stated in the book). Apologies! (and apologies for calling you Vincent by mistake in the first post LOL).

Dave