> Are there any common guidelines that help you decide, > which approach to apply in a given situation?
Nothing formal, I have only used this approach once and I used it because all of the following conditions were met: * The data was to be used for a read only, tabular display i.e. a physical representation of a recordset * The data to be displayed didn't model a real domain object * The data to be displayed was likely to be subject to significant changes in user requirements (e.g. "remove column x, add a new column y" etc) and these requests were subject to significant time pressure. Use of this pattern allowed me to drive these changes from the data source without having to touch data translation or view rendering code. I hope that helps. -----Original Message----- From: Tom Ziemer [mailto:[EMAIL PROTECTED] Sent: 18 August 2005 17:25 To: Struts Users Mailing List Subject: Re: [OT] Loading data for view Thank you, for your very elaborate answer. After reading your post, it seems that there is really no big difference between the two approaches, so I guess I'll stick with what I've already implemented. I guess losing type safety is not a big issue, since I'll only use my "special" DTOs for display purposes and thus all values are casted to stings anyway. So could we summarize this thread by saying, use DTOs only when all relationships are required and stick to custom queries when it comes to displaying data, or is this view to simplistic? Are there any common guidelines that help you decide, which approach to apply in a given situation? Regards, Tom McDonnell, Colm (MLIM) wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
