How would you do this?

cmay posted on Saturday, June 10, 2006

Can any of you guys give me your opinion on how to model this simple situation?

Lets say you are dealing with race car drives.

Each driver drives a specific model of car, and each model is a brand of car.

So Bill might drive a Boxter, which is a Porche.

=== skip this part if you don't care about the DB schema ===
In the DB, the Driver has a CarModelId value that is a FK to the CarModel table. The CarModel table has a CarBrandId which is a FK to the CarBrand table
So each driver has a car model, and each model has a brand.
=== end DB part ==

Now, when creating the Driver class, and the form to edit the drivers info, would you say that the Driver is the parent of a Car object, which contains both the Model and Brand, or would you just have the Driver contain 3 properties: iCarId, sCarModel, sCarBrand ?

If you think I should use an object instead of the 3 properties, how would I "mark" that object. I don't think it should be readonly b/c I want to be able to change what car is assigned to that driver, but I don't want to update the car object itself (e.g. I want to change Bill from driving a Boxter to driving a 911; I don't want to change the NAME of the Boxter to "911" in the database)

Any suggestions which path would be corret?

Q Johnson replied on Sunday, June 11, 2006

You need to break this "simple situtation" down into all the use cases you need to support.

Your focus seems to be on a use case relating to the assignment of a car to a driver. But you may need some or all of these others:

1 Create/Modify Make List (Brands)

2 Create/Modify Model List

3 Create/Modify Car (which would have Model and Make/Brand property values at a minimum and perhaps several others including, perhaps, a list of possible drivers or even a driver history)

Your implementation of the driver class will be affected, of course, by the availablility (or lack) of those other objects. You certainly want to have your driver class offer text representations of Car, Brand/Make, and Model for the UI (which will all be properties, of course). But any or all of these may be tied to other objects or not. Your implementation of the class might involve the use of ID fields to pull data from other tables, of course. But don't put those IDs into the properties here. That's just data-centric object thinking.

You drive a car (or cars), right? Do you think of your car by its VIN? The user of your driver object probably doesn't think about the race car that way either.

If your application is successful with the capability of a model in which there is one driver to one car, you should probably be expecting to need to enhance it in the future for scenarios in which more than one driver might drive a car or a driver might drive more than one car. It might be to enlarge the scope to mulitiple races during some time frame or it might be to provide race history. You should probably consider those N-to-N drivers-to-cars requirements in the design of current version so that the enhanced functionality will be easy to provide in the future, if needed.

SonOfPirate replied on Sunday, June 11, 2006

One more thing to keep in mind, that I think has been lost so far, is that the car's model & brand are singular to the Driver. You wouldn't want to be able to assign a Boxter model and Ford brand. The DB model you described does tightly-couple the brand to the model, so a Boxter directly corresponds to Porche as would be expected. But, from the driver's perspective, he/she is assigned a Porche Boxter and the user should not be given the option of assigning from a list of models AND a list of makes.

With this in mind, I would agree that the sample app included in the book describes this scenario very well and your model will suffice for a very basic application. You should look at the N-to-N approach; however, as it probably models real-world better.

Anyway, what you'd have is a Driver object with a Model property that references the particular object assigned to that Driver. In your drop-down list of cars to assign to the driver in your UI, a read-only ModelList can be set as the data source. Set your unique key as the drop-down list's key/value and the ToString() method for the text. Then, override the ToString() method in the Model object to:

public override System.String ToString() { return Make.ToString() + " " + this.Name; }

The result will be a list of names like "Porche Boxter" which will make more since to your users when assigning the cars.

Hope this helps.

cmay replied on Sunday, June 11, 2006

I understand that N-to-N cardinality might seem like a good way to design this, but in the context of my application doesn't really apply.

Unless I missed it, the examples in the book use collections where the child object knows which parent it belongs to.

So if I was going to say that each driver could have a collection of cars, and I added an extra table to the DB to do this, then the example would line up pretty well.

But, instead of having a CarAssignment table, or something like that, the Driver has the CarId as part of his table, b/c he can only have 1 car.

So is it correct that what I should be doing is

1) create a ReadOnlyChild object to represent the Car (meaning that you can't change the car name or brand)
2) make the property on the parent a read/write (meaning you can assign a different car)

Does that sound right?

jinchun replied on Sunday, June 11, 2006

I would actually do just that. From my own personal experience, it is much easier to keep parent/child relationships in object extremely flat, meaning, you can always logically get from one to the other, whether through direct object references, or unique id's/natural id's that associate one to the other. From what I have found, it is much simpler to do the latter in most non-trivial circumstances, which also seems to ease mapping to tables relatively straight forward.

cmay replied on Monday, June 12, 2006

I built a form to edit my Driver, but now I have a problem with editing.

I had planned on having a car dropdown list to select from, built from NameValueList, but I don't think I can do that b/c my driver has a property for Car, not a property for CarId.

So should I be databinding against a dropdown that has a collection of Car objects, rather than a NameValueList?