On 8/29/07, Justin Treher <[EMAIL PROTECTED]> wrote: > > I guess I need to dive into an ORM now that I'm experiencing the problem > it solves. > > > Composition, delegation, and aggregation seem to be tough concepts for me > to understand with respect to when I should be using them vs. a structure > that is filled from the database. > > Example: > > Blog has a property categories > > We need a select list filled with possible categories for our new blog > entry. Is that select getting category information from a category object or > is this a struct filled from somewhere? > As always, it depends. You can call category.getAll(), but I don't like that. Generally, Category would model one category. I would have a CategoryService and call categoryService.getCategories(). And if you don't have much more category functionality it may be enough to have a general BlogService and just call blogService.getCategories().
> I've been handling this situation like this: > > Blog's categories property is an array of category objects. Category has > its own bean, GW, and DAO. While this seems ok because I need to edit > categories independently, category really doesn't have any behaviors. > A bean doesn't have to have behavior, and if all it is doing is representing a row in the database, it may have no behavior other than getters and setters. > So do I pretty much handle all properties of this type like that? > > > Address -> State is an object of State > > Members ->MembershipTypes is an object of membershipType > > Books -> BookType is an object of BookType > > Wand -> Materials is an array of objects WandMaterial > Again, it depends. It's probably overkill to have a separate object just to represent a state. The others fall into the grey area. If they are nothing but data containers, you might not need separate objects for any of them. You certainly can if you like (and with the help of all the code generators out there this may be fine). You could also create some general object(s) that save and get these basic kinds of data for now. The key there is to make sure that you keep things as encapsulated as possible so that if, later, you decide you DO need a full blow MembershipType object, it is easy to make that change. That is probably the best advice to highlight: however you choose to do it, take extreme measures to make it easy to refactor later. That means making changes in only one place, and make sure that the impact of a change is isolated and doesn't ripple through the entire system. OO is hard. It's easy to overdesign, and just as easy to underdesign (or end up with a bunch of procedural code that is just sitting inside a method). Avoiding these requires experience combined with an understanding of the problem being solved. You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
