well it has a department ID, not another object. If I'm bringing back 1000 employee records for my datagrid, I already have to loop over that query on the backend to create the array of 1000 VOs. I don't want to have to query to get a Department VO for each iteration as well, when all I need is that name and it already exists in my BO by way of a lookup table.
I store these lookups in my business logic and use them in comboboxes and such (this collection populates the Department dropdown on the Employee). usually i only bring them back with ID and Name. I want to use these collections to get the name for an ID at any time I need it. The list of departments is a list of simple objects, I didn't see the need to create VO's for such things. However I'm obviously doing something wrong. I imagined I would have to write renderers for the datagrid and that would be easy enough, but that's not the only place I display data from lookup tables. In Labels, Tab Headers, all sorts of places need to get the department name from the department ID in the employee VO (for one example). Should I just bring the department name back in the employee VO? I'd rather not, it doesn't seem right- but if that's the way to do it I will. D. On Tue, Sep 2, 2008 at 10:34 AM, Douglas Knudsen <[EMAIL PROTECTED]>wrote: > 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? > >
