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]
