Sounds like you're using a data transfer (tree)map pattern, this is
largely similar to the rowset version except for the following:
* You have to copy values from the underlying data access
solution into the TreeMap
* Your view component needs to know about the contract for
attribute keys in the map (or perhaps not, perhaps this is
why you are using a TreeMap)
In the rowset version you would wrap a disconnected recordset along with
some meta data then use this meta data in your view component e.g.
iterate over the metadata to output column headers for your table, then
iterate over the data rows to output your data rows.
Which is better? No cut and dried answer but here are the pros and cons
for both so that you can decide.
Rowset Approach
---------------
Pros:
* Common interface for all general purpose, read only query
operations
* Enables you to write generic table display code by using
taglibs to iterate over the rowset/map
* Responds well to change - the absence of a data translation
layer coupled with the use of generic table display code
leaves you view indifferent to changes in the underlying
data set
Cons:
* Clients need to know the name of database table columns
* Bypasses the domain model, breaks some rules about separation
of responsibilities (this shouldn't be a showstopper if it is
used in carefully controlled situations such as displaying
read only data in a tabular manner)
* Loss of type safety (no compile time checking)
Map Approach
------------
Pros:
* Minimises the data translation layer (assuming you can generically
translate a record set into a map)
* Enables you to write generic table display code by using
taglibs to iterate over the rowset/map (assuming you can make
assumptions about the order in which the map entries are stored)
* Responds well to change - although not as well as the rowset version
Cons:
* Clients need to know about the contract governing the naming of the
map keys
* Loss of type safety (no compile time checking)
* You'll need to wrap primitives and most access will require casting
-----Original Message-----
From: Tom Ziemer [mailto:[EMAIL PROTECTED]
Sent: 18 August 2005 15:52
To: Struts Users Mailing List
Subject: Re: [OT] Loading data for view
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]
--------------------------------------------------------
If you are not an intended recipient of this e-mail, please notify the sender,
delete it and do not read, act upon, print, disclose, copy, retain or
redistribute it. Click here for important additional terms relating to this
e-mail. http://www.ml.com/email_terms/
--------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
