Well, if your code is well designed your artist fetch logic is
probably in the Artist class
Many queries aren't really "artist fetch logic" but ad-hoc statistics stuff. The kind of query with aggregate functions.
A query DSL should be built for ad-hoc queries anyway. Fetching the data model from the database is already covered at the entity bean layer, tailoring the DSL for the ad-hoc queries is going to gain Cayenne more new power than tailoring it for predesigned fetch logic.

Besides, the argument loses some weight as soon as subqueries and joins come into play.
You could move those parts of the query to the other class, but you'd have to wrap each snippet that you move in a function, give it a name, and call it from the main class. Might give you a better design, or might be hopelessly overengineered.
so the class name isn't needed.
If you are doing something inside the class you can use a
static import to move all the artist stuff into the
namespace and then use it without qualification.
'Artist.' would be the lesser evil when it comes to quick coding, as it can leverage code completion (static imports can't because the list of potential matches would be huge).


Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 22 of 22 | next ›
Discussion Overview
groupdev @
postedJan 26, '12 at 5:16p
activeFeb 1, '12 at 9:31a



site design / logo © 2022 Grokbase