Hi All,

I have been thinking for some time about what I believe would be a useful extension to the Spring framework, specifically to the DAO and ORM areas, in the form of a generic, OO query API.

I find that the different competing ORMs have some sort of OO based query API, a good example of which (and which I often use) is Hibernate's Criteria API. But there are a number of problems I have with Hibernate's Criteria API, being:
  • a) Not portable between ORMs (only works with Hibernate)
    b) Tied to a hibernate Session. You cannot just create a Criteria out-of-session, populate it, then re-use it later in a different session.


I think a generic Spring query API, similar to Hibernate's Criteria API, would be extremely useful. The features it should have would be:
  • a) Object Oriented. A query exists as a type-safe object, rather than as a language-specific query string,
    b) Possess common ORM/dao query features - including the following:
    [list:d7ba361e6a] i) Selection set,
    ii) Conditions/filters,
    iii) Fetch sets (eg. for pre-fetching lazy relationships),
    iv) Grouping,
    v) Ordering,
    vi) Result format (ie. List vs Unique result object)

b) ORM independent. Query objects should exist independently of the ORM chosen to implement a DAO, and be re-useable between different ORMs (jdbc, Hibernate, jdo, ojb, etc),
c) Disconnedted from data-access layer. In other words, the query could be created anywhere, in the View or in the service layer, with no dependence on a jdbc connection/hibernate session/etc, in order to be created or exist.
d) Configurable via xml - to allow defining queries in spring xml context files,
e) Helper translators for all supported ORMs - to allow a query to be transalated into a Hibernate query (Criteria), JDO query, OJB, jdbc, etc,[/list:u:d7ba361e6a]
Some of the perceived benefits of such an API would be:
  • a) Allow for the removal a lot of repetitive DAO code, or even allow just using a generic DAO for all service implementations,
    b) Allow for dynamic queries that could be, for example, driven by human input.
    c) Allow for persistence of query objects (eg. user on a website defines preferred filters, saves them for later re-use),
    etc.


Does anyone have any thoughts/comments on this?

regards,
Scott Russell