if I grasped your idea... a way to do this is rely on a NameValueList that "translates" codes to descriptions.
Some templates "cache" the list in a static variable so it does not hit the database a lot.
So if your BO persists an EmployeeTypeId the NVL would translate the ID to the Description
string desc = EmployeeTypeNameValueList.GetInstance().GetValue("code");
HTH.
That's great if you don't have conditional code that depends on these properties. In my case I have lots of ReadOnly lists/lookup tables in the db (e.g. EmployeeType). If I need to create business rules on my Employee object based on employee type or anything depending on that value, to avoid weak typing I would have a static class containing constants for all Employee Types (hard-coded) and a static method that returns a hard coded description for a given code.
I know that its lots of hard coded values but I prefer that (since these values will hardly ever change) rather than weakly typed code. But any comments on this would also be appreciated.
It is perfectly fine to have "extra properties" (also called borrowed properties) in your BO.
In a normalized DB you will have many "code fields" in your table. When you build a BO for that table you will obviously store all the fields for it. But your users will want to see the descriptive text for each code field. So when you fetch the BO you should also fetch the corresponding description for each code field.
The question is - how and where do you get this description value? The other posters are suggesting you have separate BOs for them which is fine in many cases. There is nothing wrong with adding some JOINs to your SQL to fetch fields from related tables.
Joe
Copyright (c) Marimer LLC