使用映射到数据库中某些种子数据的枚举是不好的做法吗？

我在我的数据库中有一个名为“OrderItemType”的表，它有大约5个记录，用于我系统中不同的OrderItemTypes。每个OrderItem都包含一个OrderItemType，这给了我参照完整性。在我的middletier代码中，我也有一个枚举，它与此表中的值相匹配，以便我可以为不同类型创建业务逻辑。使用映射到数据库中某些种子数据的枚举是不好的做法吗？

我的开发经理说，当人们这样做时他讨厌它，我不确定为什么。我应该遵循更好的做法吗？

来源

2010-04-29 skb

我一直这样做，我没有看到任何错误。事实是，有些值对于你的应用程序是特殊的，你的代码需要对这些值作出不同的反应。你的经理会不会硬编码一个Int或一个GUID来识别Type？或者他宁愿从OrderItem中为数据库中的每个不同类型派生一个特殊对象？这两者都比枚举糟糕得多。

来源

2010-04-29 16:35:09

我没有看到存在枚举值存储在数据库中的任何问题，这实际上阻止您的代码处理无效的代码类型。实际上，我开始这样做后，我的问题开始减少了。你的经理是否为他的仇恨提供任何理由？

来源

2010-04-29 16:34:57

我们也这样做。在我们的数据库中，我们有一个我们映射到代码中的Enum值的Int列。

来源

2010-04-29 16:35:06

如果您对每种特定类型都有真正的商业关注，那么我会保留enum并将其放在数据库中。

这种做法背后的原因很简单：

你添加一个订单类型每一次，你将不得不添加业务逻辑吧。因此，证明它存在于你的业务领域（无论它是否是枚举）。但是，在这种情况下，让它在数据库中不会为你做任何事情。

来源

2010-04-29 16:35:44 Joseph

你假设订单类型是基于订单的性质的计算值，否则，你也不一定能从数据库中再水化对象。 – 2010-04-29 16:38:30

@Jacob不，我不假定它是计算出来的，用户可以将它作为一个字段存储在OrderItem记录中，而不是让整个子表跟踪它。我的观点是创建一个OrderItemType表没有太大的需要，但他仍然需要在OrderItem中保存枚举值。 – Joseph 2010-04-29 17:15:53

@约瑟夫：啊，“把它放在数据库中”的评论听起来好像你主张完全删除它。我为我的误会道歉。我喜欢保持这些数据的正常化，以便我可以更容易地将它们别名显示，如果有必要的话。 – 2010-04-29 17:23:44

我已经看到这样做是出于性能的原因，但我认为在大多数情况下使用缓存机制是完善的。

来源

2010-04-29 16:43:47 CodeGrue

帮助同步数据库值和业务逻辑枚举值的另一种方法是使用EnumBuilder类从数据库中动态生成包含当前枚举值的.dll。然后您的业务逻辑可以引用它，并具有智能感知支持的同步化枚举值。

它实际上比它听起来复杂得多。

下面是MSDN的链接，以解释如何动态构建枚举。
http://msdn.microsoft.com/en-us/library/system.reflection.emit.enumbuilder.aspx

你一定要分了与数据库访问代码获取枚举值：

来源

2010-04-29 16:51:51 balazs

你一票，我也用映射数据库INT < - >应用枚举，此外，我一般形容我的枚举是这样的：

public enum Operation 
{ 
    [Description("Add item")] 
    AddItem = 0, 

    [Description("Remove item")] 
    RemoveItem = 1 
}

这让我完全免费，无需更改数据库，并在很短的解决方法，我可以用含有描述（这是非常强烈依赖于数值列表的工作，即增加新的价值！） - 只是一点点的反思达到了目标！

在代码中，你通常可以只添加一个属性是这样的：

public class Order 
{ 
    public int OrderTypeInt; 

    public OrderTypeEnum OrderType 
    { 
     get { return (OrderTypeEnum)OrderTypeInt; } 
     set { OrderTypeInt = (int)value; } 
    } 
}

来源

2010-05-11 01:06:51

使用映射到数据库中某些种子数据的枚举是不好的做法吗？

回答

相关问题