I guess this is another question about hard coding and best practices. Say I have a list of values, lets say fruit, stored in the database (it needs to be in the database as the table is used for other purposes such as SSRS reports), with an ID:
1 Apple 2 Banana 3 Grapes
I may present them to the user, he selects one, it gets stored in his profile as FavouriteFruit and the ID stored in his record in the database.
When it comes to business rules / domain logic, what are the recommendations for assigning logic to specific values. Say if the user has selected Grapes I want to perform some extra task, what's the best way to reference the Grapes value:
// Hard coded name if (user.FavouriteFruit.Name == "Grapes") // Hard coded ID if (user.FavoriteFruit.ID == 3) // Grapes // Duplicate the list of fruits in an enum if (user.FavouriteFruit.ID == (int)Fruits.Grapes)
or something else?
Because of course the FavouriteFruit will be used throughout the application, the list may be added to, or edited.
Someone may decide that they want 'Grapes' renamed to 'Grape' and this would of course break the hardcoded string option.
The hardcoded ID isn't completely clear although, as shown you could just add a comment to quickly identify which item it is.
The enum option involves duplicating data from the database which seems wrong as it may get out of sync.
Anyway, thanks in advance for any comments or suggestions.
MyApplication.Grape.IDis stuttering, so to speak. A "Apple" is not a "Red_Apple" any more than ID of 3 is also 4. So the potential for renaming "Apple" to "Red_Apple" makes no more sense than declaring that 3 is 4 (and maybe even 3). The point of an enum is to abstract away its numeric DNA. So maybe it's time to really decouple arbitrary relational DB keys that have literally no meaning in one's business models.