I'm just wondering what the concensus is on handling simple classifications or types on an object. Consider the class Worker. Worker can be of type "Salary", "Hourly", or "Contractor" or additional types defined by the user. In the database this is is represented by WorkerType(Int id, description varchar); How is this represented on the Worker class?
1. Worker.WorkerType where WorkerType is it's own class having both the id, and the description fields? This makes the most sense to me from a design perspective but is difficult to use. How would you bind it for display in a grid? How would you change it?
2. Worker.WorkerTypeId is only the id field? By far the easiest for updating but what do you do to display it in a grid? Do a lookup as each item is bound?
3. Add Worker.WorkerTypeDescription? Fixes the display issue, but do you do something to ensure that WorkerTypeDescription stays in sync with WorkerTypeId if WorkerTypeId is changed?
I use #2 in the book, because the combobox controls in Windows, web and WPF all handle translating the numeric value into a human-readable value with little effort.
Yes, I agree that combo/dropdown boxes are easy in this case, but what about in a grid (specifically in a web page)? Do you translate the value in one of the grids ie ItemCreated or ItemDatabound? I would like to avoid a special RO collection of WorkerInfo objects just for display, at least in simple cases like this.
I've been doing some thinking on this problem, and came up with several approaches. Haven't tried them out yet to see which one I like best. :(
brrrdog:
1. Worker.WorkerType where WorkerType is it's own class having both the id, and the description fields? This makes the most sense to me from a design perspective but is difficult to use. How would you bind it for display in a grid? How would you change it?
You could implement a WorkerTypeNVList, a subclass of the NameValueListBase class. If the WorkerType class (of BusinessBase) is implemented correctly, WorkerTypeNVList always stays up-to-date. See #2 and #3 below on how this might be used.
2. Worker.WorkerTypeId is only the id field? By far the easiest for updating but what do you do to display it in a grid? Do a lookup as each item is bound?
If you use a DropDownList to display the WorkerTypeId property, you can use the WorkerTypeNVList to supply the corresponding values, and thus display the description for the user.
3. Add Worker.WorkerTypeDescription? Fixes the display issue, but do you do something to ensure that WorkerTypeDescription stays in sync with WorkerTypeId if WorkerTypeId is changed?
If you chose to go with a property for the description field, it could look up the correct value in the WorkerTypeNVList class on demand. For large lists, this might save a lot of memory.
(Then again, maybe .Net is smart enough to somehow know the 20,000 Workers of Type = WorkerBee only need one string storing "WorkerBee", instead of 20,000 copies.)
At the least, if someone changes the description of WorkerBee to WorkerDrone, this should pick it up automatically, the next time someone asked. If the literal value was stored inside the object as a string, it wouldn't (without additional coding).
One thing to consider is separation of concerns. It is a UI concern to translate values into human-readable output. It really isn't the business object's job to provide the text description (though I sometimes do so in read-only objects too ![Smile [:)]](/emoticons/emotion-1.gif)
).
But I think the correct solution is to handle the proper event in the grid (the name of which escapes me) that allows you to format a value as it goes into the cell/column. That gives you the opportunity to translate from the integer value to the string value for the user.
The UI then has the job of getting the NVL to do the translation, but that's a small matter.
And in CSLA 3.0 I'm adding a GetValue() to NVLB to make this sort of thing easier (right now you may need to loop the list to find a match).
Copyright (c) Marimer LLC