I have a data object (let’s say it’s called ‘Entry’) that has a set of potential states that look something like this:
1 - Created 2 - File added 3 - Approved 4 - Invalid
This is represented in the database with a ‘Status’ table with an autonumber primary key, then a ‘StatusId’ field in the main table, with the appropriate relationships set up.
In my (custom) data layer, I have the ‘Entry’ object, and, currently, I also declare an Enum with the states listed above specified. Finally I declare a private instance of this Enum along with the appropriate public property.
In my ‘Commit()’ method I cast the instance of the Enum to an integer and pass it to an Update stored procedure.
In my static ‘GetEntry()’ method I will obviously have an integer passed back from the database. I then use the ‘Enum.Parse()’ method to extract an object which is an instance of my Enum which corresponds to the returned status integer. I cast this to the type of my Enum and assign it to the local private variable.
My question is pretty simple – is this approach appropriate, and if not what alternative, other than just storing the raw integer value (which i’m not necessarily averse to), is better.
My reason for asking is that this all just seems incredibly messy to me, what with all the casting and maintaining two lists of the same set of values. I accept the benefit lies in a better experience for the consumer of the data object, but even so…
Thanks!
We have something familiar in one of our projects. We have a table containting types of items. These types have an id, in the code we have an enum with the same id’s. The thing is, in the database we don’t use autonumber (identity) so we have full control of the id. And when saving our object we just take the id of the enum to save the object. I also thought this approach was messy but it’s not that bad afterall.