使用 Enum 表示数据层对象的“状态”； 在 C# 中
我有一个数据对象（假设它称为“Entry”），它具有一组潜在状态，如下所示：
1 - Created 2 - File added 3 - Approved 4 - Invalid
这在数据库中用带有自动编号主键的“Status”表表示，然后是“StatusId”主表中的字段，并设置适当的关系。
在我的（自定义）数据层中，我有“Entry”对象，并且当前，我还声明了一个具有上面列出的指定状态的枚举。 最后，我声明此枚举的私有实例以及适当的公共属性。
在我的“Commit()”方法中，我将枚举的实例转换为整数并将其传递给更新存储过程。
在我的静态“GetEntry()”方法中，我显然会从数据库传回一个整数。 然后，我使用“Enum.Parse()”方法提取一个对象，该对象是我的 Enum 的实例，对应于返回的状态整数。 我将其转换为枚举类型并将其分配给本地私有变量。
我的问题很简单 - 这种方法是否合适，如果不合适，除了存储原始整数值（我不一定反对）之外，还有什么替代方案更好。
我问这个问题的原因是，这一切对我来说似乎非常混乱，所有的转换和维护同一组值的两个列表。 我承认这样做的好处在于为数据对象的使用者提供更好的体验，但即便如此......
谢谢！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我们的一个项目中有一些熟悉的东西。
我们有一个包含项目类型的表。 这些类型有一个 id，在代码中我们有一个具有相同 id 的枚举。
问题是，在数据库中我们不使用自动编号（身份），因此我们可以完全控制 id。
当保存我们的对象时，我们只需使用枚举的 id 来保存对象。
我也认为这种方法很混乱，但毕竟还不错。
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.
这个方法我觉得不错。
过去我也做过同样的事情，但也有一个表，其中包含枚举的每个成员的一行，该表是任何使用枚举值的表的外键，这样读取数据库的人就可以理解什么每个状态都无需查看实际的枚举。
例如，如果我有一个枚举，就像
我会有一个名为 status 的表，其中包含以下记录
ID 姓名
0 活跃
1 已删除
2 Inactive
该表将成为使用该枚举的任何表的外键。
That method seems fine to me.
In the past I've done the same thing but also had a table that contained a row for each member of the enum that table was then the foreign key for any table that used the enum value, just so someone reading the database could understand what each status was without having to see the actual enum.
for example if I had an enum like
I would have a table called status that would have the following records
ID Name
0 Active
1 Deleted
2 Inactive
That table would then be the foreign key to any tables that used that enum.
是的，这很好！
请始终像这样显式设置值。 这样，如果有人去添加一些东西，他们就会意识到这些值很重要，不应该被搞乱。
如果您通过 WCF 传递值，我建议添加
否则，如果您尝试序列化来自数据库的 0，您将收到一个可怕的错误，并且将花费您永远进行调试。
Yup this is fine!
PLEASE always explicitly set the values like this. That way if someone ever goes to add something they'll realize the values are important and shouldn't be messed with.
If you're passing the value around via WCF I'd recommend adding
Otherwise if you try to serialize a 0 coming from the database you'll get a horrible error and it'll take you forever to debug.
数据库查找表是必要的； 编程枚举可以方便地避免代码中出现“幻数”，但是，则不需要枚举
如果您的代码不需要操作状态，则
the database lookup table is necessary; the programmatic enum is convenient to avoid having 'magic numbers' in the code
if your code does not need to manipulate the status, however, then the enum is unnecessary
我一直使用枚举来实现这种方法。 如果它是一个简单的项目，比如状态，预计不会改变，我更喜欢枚举。 解析和转换是一个影响非常小的操作。
我已经使用 Linq to Sql 成功完成此操作一段时间了，没有出现任何问题。 Linq 实际上会自动在 Enum 和 int 之间进行转换。
代码不仅仅关乎速度，还关乎可读性。 枚举使代码可读。
直接回答你的问题，这是一个非常有效的方法。
I do this approach with Enums all the time. If it is a simple item like status that is not expected to change ever I prefer the Enum. The parsing and casting is a very low impact operation.
I have been doing this successfully with Linq to Sql for sometime now with no issues. Linq will actually convert from Enum to int and back automatically.
Code is more than just about speed but readability. Enums make code readable.
To answer your question directly this is a very valid apporach.
如果您的代码需要设置已知的“状态”值（您在枚举中定义的），那么可能还要求这些“状态”值存在于数据库中。 由于它们必须存在，因此您还应该可以控制分配给每个值的 Status_ID。
删除身份并仅显式设置查找值 ID。
If your code requires setting known "Status" values (which you've defined in your enum), then it's probably also a requirement that those "Status" values exist in the database. Since they must exist you should also have control over the Status_ID assigned to each of those values.
Drop the identity and just explicitly set the lookup value IDs.