i get it, thanks doug! On Wed, Sep 3, 2008 at 10:49 AM, Douglas Knudsen <[EMAIL PROTECTED]>wrote:
> 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? > >
