Question

In an n-tiered application where you are using custom entities, how do you find yourself handling data needed from lookup tables? Do you create entities for each of these lookup tables or employ some other strategy?

For example. I have a ‘Ratings’ lookup table that will be used to populate a dropdownlist. Would you create a ratings object with a ratingid and rating property and pass that to your UI or is there a more efficient way to go about it?

Appreciate your thoughts.

Answer 1

I’d suggest that the solution will depend on how often the lookup data changes, whether or not it needs to be editable, and whether or not you’re enforcing referential integrity at the database. I think it makes the schema more understandable if you put each lookup type into a separate table.

I generally don’t create entities for each lookup table, but instead will load most of the common lookups into structures that are easily re-used by the application – for an asp.net app, for example, I’ll create hashtables or ordered dictionaries which can easily be bound to most web controls.

And, horror of horrors, I sometimes create a singleton to manage access to all these lookups, which can be stored as static vars or in the cache, depending on requirements.