So, I think the research is going well, but I have a few more questions regarding these DAO, Bean, and Gateway objects.
Image if you will a blog entry. Entries can be related (related topics) and therefore I have a blog_entry_blog_entry_jn table (my company's naming conventions). Now, the related entries may or may not be properties of a blog entry. I have decided that No, they are not, they are more an understanding of the blog system rather than a property of any given blog entry. And so, I have a BlogEntryGateway that has: SetRelatedEntries(ID, RelatedIDs); --> Return void GetRelatedEntries(ID); --> Returns query object I think I am happy with that, but would LOVE some feedback on the idea. But, the query object being return now raises more questions, specifically about the breadth of information being returned. Right now I am returning all the columns. But, lets say I have a page where I just want to list out the related titles and link to them. For that, all I would need is the ID and the title. But, then on other pages, I might want more than that. The question then becomes, do I control the number of columns being queries and returned. I would rather query less columns = less data to move around, but what do I do down the road if a page needs a different column? I thought about passing in a list of columns to the method call, but that seems clunky and not as easily maintainable. Thoughts, help, comments, suggestions? Thanks! Ben ...................... Ben Nadel Web Developer Nylon Technology 6 West 14th Street New York, NY 10011 212.691.1134 212.691.3477 fax www.nylontechnology.com "Vote for Pedro" ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
