最佳实践：使用枚举或不存储下拉值

Question

I'm developping an application and I often ask myself the same question.

For example, I have many types of user and in a form used to create a user, there is a dropdown to specify which type of user.

The best way to populate this dropdown is to store values in a database's table ? If I do this, when I develop I want to test type of user and I have only an int. But I thing it's a better practice to test with enum. So I create enum but I feel it's a bad practice because I have to keep database and enum synchronized.

Another question is about localization. If I put values in database, I can't use resource file.

Could you tell me good pratices about this ?

Thanks

Answer 1

in your situation - the database would be the best practice here especially if its dynamic data. enum is for those values which are rarely to change, maybe once in a while but not on a frequent basis. you may have new entries entered in the database regularly especially for things like cascading drop down lists.

database certainly is the way to go in your situation. Enums are there for those times where they are just a set standard and rarely to change, for example:

Mr. Miss. Mrs. Ms. Dr.

you would have these in enums as they will never really change. on the other hands if store departments are to be changed or renamed, database would be the place to store such entries.

Answer 2

I strongly disagree with using enums for this kind of functionality, for basically two reasons:

• Enumeration values have no behaviour, so compromise good OOP. A good class has data + behaviour, so enumeration members are not sufficiently specialised to represent the concept they are named for. The logic concerning this domain object lives somewhere else other than the entity that bears its name, which I dislike.
• Enumerations are meant to convey ordinality, so DaysOfWeek is a good usage (except that which day of the week is 'first' varies depending on culture, but that' nitpicking) because the enumeration denotes the order of its members. In your case, does it make sense to say that a particular value is the 'first' user type, the second value is second, and so on? Probably not.

Answer 3

My first question would be - do you actually use the user type anywhere in the database? If the answer is no, everything is easier, since you can simply use an enum and be done with it.

Otherwise, you probably should have a user type table as well, to get to use foreign keys properly.

Personally, I use manual ID for these - autogenerated keys can make a mess of your attempts to synchronize code and database. Ideally, if your ORM allows it, you could have the code-database synchronization automatic - either through code generation, or through automatic database data update. If you can't, though, manually coding the enums (or some kind of pseudo enum) should still be a lot nicer in the code.

As for localization, your options are completely the same. Just use a resource key like "UserType-XXX", where XXX is the database ID of the type. If you want, you can also store the localized values in the database. Just do whatever feels the best for your application.