Thanks for your answers.
I added a new method to my DAO that allows me to execute predefined
queries and returns kind of "general-purpose-dto"s, that only consist of
a treemap which stores the requested values from the db. So I get one
g-p-DTO per row in my ResultSet that can be passed to the view for
rendering.
Is this a bad design? Is the "Transfer RowSet pattern" suggested by Colm
a cleaner approach?
I am wondering whether this is not a common problem for any application
that is based on database with a hierarchical design. Most of the time
you won't need an entire object tree but only parts of it.
Regards,
Tom
Frank W. Zammetti wrote:
Sometimes the simplest answer is the best... and even when it isn't the
best, it's *still* simple :) ...
How about just creating a new DAO/DTO that only contains the data you need?
It would be a duplication to a degree, but that's not *always* an
absolutely evil thing... especially since it sounds like the new A object
you want to display on the page may not truly model a real domain object
(where they others I presume are) but is instead something of a hybrid, I
could personally live with this.
Either that, or I would just create a single Miscellaneous DAO that has
methods that don't *quite* fit in other DAOs... maybe this is one of
them... then you would still have a DTO for this particular case, and a
new one for each particular case in the DAO, if any more came up.
FYI, most of my apps have the true DAO/DTOs, but they all also have such a
miscellaneous class for handling things exactly like this. There tend to
be very few such cases, but they do come up, and I find this to be a nice
way to organize them. In fact, in a couple of cases I've decided to make
the DTOs inner classes of the DAO, just to make it obvious they are
related and probably limited in their use cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
