On Fri, Jun 5, 2009 at 3:51 PM, Michael Dick <[email protected]>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:[email protected]
