I'd use 3 separate classes whether it was flat or not: Person, Car, CarRanking
I'd add the collection (and the back reference) as necessary (i.e. where it made sense for my application). Clinton On Sat, Nov 15, 2008 at 6:43 AM, Rick <[EMAIL PROTECTED]> wrote: > I was going to mail this directly to a few of my buds, but figured > whatever the response is, it could be useful for others... > > First the business requirements: > //hypothetical example for sake of this email: > > 1) Show a single person and their favorite cars and display the > person's rank of each car > > 2) Show multiple persons and their favorite cars and for each person > display the person's rank of their cars > > The data model looks like: > > Person > --------- > id > name > //etc > > > Car > ----- > id > name > make > color > //etc > > > Person_Car > -------------- > person_id > car_id > Integer rank > > > > So how do you guys like to set up you value objects to represent the > scenarios in 1 and 2? > > Some of you I know wouldn't like to have a > Collection<Car> favoriteCars in the Person object > > Also, what do you do about the "Integer rank?" > > Since "rank" is only one field, I'd consider adding it as a property > on Car. If there were a lot of properties (like imagine Date rankDate > , etc.) I might make a "CarRank" value object. Lets say you had the > latter (a "CarRank" object) - for you guys that do things flat how do > you return your object graph? Would you return a Map with Person as > key, and the value as a List of Maps where "Car" is key and "CarRank" > object as value? > > I tend to think in terms of adding collections to my objects as > properties, so this 'flat' concept is new to me, but I really want to > nail down this "flat" way of thinking so I can consider using it > myself. > > Thanks for any feedback. >
