使用映射到数据库中某些种子数据的枚举是一种不好的做法吗？
我的数据库中有一个名为“OrderItemType”的表，其中包含系统中不同 OrderItemType 的大约 5 条记录。每个 OrderItem 都包含一个 OrderItemType，这为我提供了引用完整性。在我的中间层代码中，我还有一个与此表中的值匹配的枚举，以便我可以拥有不同类型的业务逻辑。
我的开发经理说他讨厌人们这样做，我不太清楚为什么。我应该遵循更好的做法吗？
I have a table in my database called "OrderItemType" which has about 5 records for the different OrderItemTypes in my system. Each OrderItem contains an OrderItemType, and this gives me referential integrity. In my middletier code, I also have an enum which matches the values in this table so that I can have business logic for the different types.
My dev manager says he hates it when people do this, and I am not exactly sure why. Is there a better practice I should be following?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我一直这样做，我认为这没有什么问题。事实是，有些值对于您的应用程序来说是特殊的，并且您的代码需要对这些值做出不同的反应。您的经理是否愿意您硬编码 Int 或 GUID 来识别类型？或者他宁愿您为数据库中的每个不同类型从 OrderItem 派生一个特殊对象？这两个都比枚举糟糕得多。
I do this all the time and I see nothing wrong with this. The fact of the matter is, there are values that are special to your application and your code needs to react differently to those values. Would your manager rather you hard-code an Int or a GUID to identify the Type? Or would he rather you derive a special object from OrderItem for each different Type in the database? Both of those suck much worse than an enum.
我认为将枚举值存储在数据库中没有任何问题，这实际上可以防止您的代码处理无效的代码类型。事实上，在我开始这样做之后，我的问题开始减少了。你的经理是否为他的仇恨提供了任何理由？
I don't see any problem in having enum values stored in the database, this actually prevents your code from dealing with invalid code types. After I started doing this I started to have fewer problems, actually. Does your manager offer any rationale for his hatred?
我们也这样做。在我们的数据库中，我们有一个 Int 列，我们将其映射到代码中的 Enum 值。
We do this, too. In our database we have an Int column that we map to an Enum value in the code.
如果您对每种特定类型都有真正的业务关注，那么我会保留枚举并将其丢弃在数据库中。
这种方法背后的原因很简单：
每次添加 OrderType 时，您都必须为其添加业务逻辑。因此，这证明它在您的业务领域的某个地方是合理的（无论它是否是枚举）。但是，在这种情况下，将其存储在数据库中对您没有任何作用。
If you have a real business concern for each of the specific types, then I would keep the enum and ditch it in the database.
The reason behind this approach is simple:
Every time you add an OrderType, you're going to have to add business logic for it. So that justifies it being in your business domain somewhere (whether its an enum or not). However, in this case having it in the database doesn't do anything for you.
我看到这样做是出于性能原因，但我认为在大多数情况下使用缓存机制是更好的选择。
I have seen this done for performance reasons but I think that using a caching mechanism would be perferable in most cases.
帮助同步数据库值和业务逻辑枚举值的一种替代方法是使用 EnumBuilder 类动态生成包含数据库中当前枚举值的 .dll。然后，您的业务逻辑可以引用它，并具有智能感知支持的同步枚举值。
它实际上没有听起来那么复杂。
这是 MSDN 的链接，解释如何动态构建枚举。
http://msdn.microsoft.com/en- us/library/system.reflection.emit.enumbuilder.aspx
您只需插入数据库访问代码即可获取枚举值：
One alternative to help with the synchronization of the database values and the business logic enum values would be to use the EnumBuilder class to dynamically generate a .dll containing the current enum values from the database. Your business logic could then reference it, and have intellisense-supported synchonized enum values.
It's actually much less complicated than it sounds.
Here's a link to MSDN to explain how to dynamically build the enum.
http://msdn.microsoft.com/en-us/library/system.reflection.emit.enumbuilder.aspx
You just have to sub in the database access code to grab the enum values:
再给你一票，我也使用映射数据库 int <->应用程序枚举，此外，我通常这样描述我的枚举：
这使我可以完全自由地添加新值，而无需更改数据库，并且通过一个非常短的解决方法，我可以使用包含描述的列表（与值紧密相关） ！） - 只需一点点反思即可达到目标！
在代码中，您通常只需添加如下属性：
One more vote for you, I also use mapping database int <-> application enum, in addition, I usually describe my enums like this:
which leaves me absolutely free to add new values without need to change database and with a very short workaround I can work i.e. with lists containing descriptions (that are very strongly tied to values!) - just a little bit of reflection reaches the goal!
In code, you can typically just add a property like this: