openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Stultz <da...@6degrees.com>
Subject Re: Code organization
Date Fri, 05 Jun 2009 20:12:47 GMT
On Fri, Jun 5, 2009 at 3:51 PM, Michael Dick <michael.d.dick@gmail.com>wrote:

> Maybe I'm misunderstanding the use case, but the real coupling is the named
> queries to persistence.xml (persistence unit) - not necessarily the
> compilable unit.


This is the case for me. In my pre-JPA world I have a Widget model class and
a WidgetUtils class which manipulates Widgets, call WidgetUtils "business
logic". I might define WidgetUtils.sharpenDullWidgets() and in that method I
have

String query "select * from Widgets where Widgets.dull = 1";
... get connection, run query, traverse resultset...

I don't like embedding SQL in my Java, but I do like have the business logic
contained in the query right in the business method sharpenDullWidgets. So
really, my proposal doesn't get me what I want. Putting named queries in a
super class, a registry class or an xml file helps in that it gets the
queries out of the model but it doesn't put it in the business logic class.

Really, I think the best I could hope for is to be able to define named
queries as annotations of the method that uses it even if the method is in a
non-entity class:

public class WidgetUtils {

@NamedQueries( {
    @NamedQuery(name="findDullWidgets",
        query="select...")
})
public static void sharpenDullWidgets() {
     Query query = em.createNamedQuery("findDullWidgets");
}

The query is much closer to the point of usage. I don't think anybody would
be interested in making the above work. Of course I could write the query on
the spot and the only thing I lose is the performance of the pre-compiled
query.

-- 
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message