To BO or not to BO?

SonOfPirate posted on Thursday, May 03, 2007

My application has a number of objects that share the following characteristics:

1. All have a text "name"
2. All have a text "abbreviation"
3. Most have a numeric "code" value
4. The list of items is read-only
5. All are read-only objects
6. All change infrequently, but the potential for change does exist
7. Most would need to support parsing text equivalents
8. It would be nice to reference individual items using dot-syntax rather than through indexers
9. Localization of the text fields is a plus
10. All are used as property "types" in the application's business objects

My question is whether or not I should implement them as BO's, structs, enums, etc.

Any thoughts?

JonM replied on Thursday, May 03, 2007

The real question is how do you want to interface into them?  If end-users must be able to edit/update then a BO makes sense.  If you need to validate rules on the fields then a BO makes sense.  If you don't need anything other than read-only and you are not using the dataportal then structs and enums makes sense.

SonOfPirate replied on Thursday, May 03, 2007

I shied away from enums because of the 3-field aspect (name, abbreviation and code/value).

At this point, we are not creating an interface to manage these objects; however, despite being read-only and fixed in nature, change is inevitable and I have to keep the design open to the possibility that the code associated with an item might change, an item might be added or removed, etc.  This would be highly infrequent but it doesn't seem reasonable to recompile and redeploy should such changes be required.

The will be validation performed on the business objects that have these objects as properties, but there is no validation or security within these objects.

The use of the data portal would all depend on the approach I take.  If I go data-driven, then I would use the data portal.  If I go static, such as a struct or enum, then I wouldn't.

The big question is how to build-in the flexibility to allow change when the objects I am referring to are really just data and a BO is intended to encapsulate behavior?  Is it appropriate to go with BO's strictly because they are data-driven?

 

RockfordLhotka replied on Thursday, May 03, 2007

It sounds like you are trying to decide to hard-code or dynamically load the values.

In my experience, when in doubt, make them dynamic with caching. If there's doubt about whether they'll change - they'll change, and you'll regret having hard-coded them.