My application has a number of objects that share the following characteristics:
My question is whether or not I should implement them as BO's, structs, enums, etc.
Any thoughts?
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?
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.
Copyright (c) Marimer LLC