I suppose it depends. Bet you never heard that answer before! IMHO, if you are just displaying data in a DG or something, just use some XML and go for it. If you need to actually interact with the data, use the VOs in a architected model. Suppose your use case is that a user needs to add a department to a employee, code would be something like myEmployeeInstance.department = chosenDepartment where chosenDepartment is a Department instance. Your objects on the server would be modeled this way, model them in your RIA this way too, less work.
You may not be doing anythign wrong with your apporach, you know your use case best, eh? YMMV greatly here. It may be that having the departmentID and a lookup table is all you need really. But what about next week when suddenly a employee needs to be in two departments? I used to work with PeopleSoft data a lot, trust me rules get broken all the time :) Or maybe next month the client wants to see more info about the department? I will note that you do not need to query for the department on each employee interation in your server code. Just make your SQL return the all the (flat) data properly and while interating over it create both the Employee instance and the Department instance. DK On Tue, Sep 2, 2008 at 2:23 PM, Derrick Anderson < [EMAIL PROTECTED]> wrote: > 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? >> > > > -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it?
