Question

We're working on an hospital information system that is being written on C# and using NHibernate to map objects to database. MVC pattern is being used to separate business logic from UI. Here is the problem,

How do you get variable sized different set of strings to UI?

For example a Contact object have a property named City that holds which city contact lives. In country that the app is written for has more than 80 cities. How could you write those cities to a combo box? (or a data grid, tables, ...) In this example the city number is fixed. There is no need to add another city for a long time. (If the city list changes, recompiling is not a problem)

For example a Contact object have another property named FooBar which is going to be hold 1000 different string values and these values is going to be selected from a combo box for that property. And this set can be grown if users want. How do you load the combo box with these values? (If the string list statically written to combo box object, recompiling is a problem)

I have different solutions as below

  1. All string values statically written to combo box in code or designer
  2. Get the values from a resource file
  3. Write those values to an XML file (Actually same as above, but no need to recompile)
  4. Make a City object and get the values into a list from CITY table with NHibernate
  5. Make a class named StringHolder which has a Type and Value property. All string values(including City and FooBar) would be written in just one table named STRINGHOLDER. And get those values with a key like "CITY" or "FOOBAR" with NHibernate.

Which one would you choose? Or could you suggest me another one?

Thanks all

Was it helpful?

Solution

If the locations are actually going to be used for anything, get them into the database. If the data "isn't really used", but cities lookup is provided to make the user interface better, then the XML file option is not a bad way to go either.

By used, I mean stuff like list all emplyees in New York and stuff like that. If it's "dead data", just to be displayed, go for the solutions that will require the least amount of work and least risk - which might be the file option.

OTHER TIPS

I would vote for solution #4. That's the way I have always done it in similar situations. It just seems like a cleaner solution.

How do you feel of using List<string> for a list of City? Load this list of strings in your DAL or BL and then pass it on to UI.

Same solution should be good for FooBar values too.

In case you have IDs associated with City or FooBar, say NY and its numeric ID in DB is 1, then you can use KeyValuePair<TKey, TValue>. With generics you can dictate what data goes in this KeyValuePair. City name or FooBar's string value can be key and numeric ID can be value.

Just 2 cents.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top