So, your Employee class 'has a' Department, eh? Smells of composition. Employee should maybe have a public var department:Department; inside it. YMMV though, if you really need your VO to be flat for say easy DG only use or some such.
DK On Tue, Sep 2, 2008 at 5:01 AM, Derrick Anderson < [EMAIL PROTECTED]> wrote: > Hi, I've been going thru my app now that I know the magic of VO's and > converting most things to value objects- loading my VO's into datagrids, > forms, all is great. > > I do have 1 question though, let's say I have a 'employee' value object > that has the property 'departmentID'. Is it common practice to also include > the 'departmentName' in the value object? I already have a collection of > departments (departmentID,departmentName) value objects, I want to be able > to at any point find the corresponding department record so I can display > the name. Keeping it in the VO seems like a hack though, sounds like it > would leave the application open to display sync issues (name in department > vo is updated but the customer vo is not). I know I can write a renderer > for the datagrids to show the related values from other collections, but > there are other display situations too and I don't want this getting out of > hand. > > So I guess the question is, what's the best way to handle foreign key > values when dealing with VO's? Include the related values in the VO, or > look them up each time? > > thanks, > d. > > -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it?
