有很多枚举值有什么害处吗？ （很多＆gt; = 1000）

Question

我有一大堆错误消息，我的商业代码可以根据输入的内容返回。该列表最终可能超过一千个。

我想直接枚举这些内容，使用[Description（“”）]属性记录友情信息。

类似的东西：

public enum ErrorMessage
{
     [Description("A first name is required for users.")]
     User_FirstName_Required = 1,
     [Description("The first name is too long.  It cannot exceed 32 characters.")]
     User_FirstName_Length = 2,
     ...
}

我知道枚举是原始类型，特别是整数。对那么多整数应该没有任何问题，对吗？

有什么我没想到的吗？这似乎应该没问题，但我认为我应该在花时间这样做之前询问社区。

当有很多值时，.Net是否会关注枚举类型？

更新

我不想使用资源的原因是因为

a）我需要能够使用整数值引用每个唯一的错误消息。除了其他内容之外，biz层还为API提供服务，并且必须返回表示错误的整数值列表。我不相信Resources允许您使用整数来处理资源值。我错了吗？

b）没有本地化要求。

Answer 1

我认为枚举中包含1,000多个值的设计需要更多思考。对于这种情况，听起来像是“上帝恩赐”的反模式。

Answer 2

我指出在属性中使用友好描述的主要缺点是，如果您需要将应用程序本地化为另一种语言，这将带来挑战。如果这是一个考虑因素，那么将字符串放在资源文件中是个好主意。

枚举本身应该不是问题，尽管在一个主列表中包含所有错误代码可能会令人困惑。您可以考虑为单独的返回代码类别创建单独的枚举，因为这将使开发人员更容易理解特定函数的可能返回值。如果代码必须唯一，您仍然可以为它们提供不同的数值（通过明确指定数值）。

另一方面，.NET BCL没有充分利用返回代码，并且在现代.NET开发中有些不鼓励使用返回代码。它们会产生可维护性问题（您几乎不会删除旧的返回代码或冒着破坏向后兼容性的风险），并且它们需要特殊的验证逻辑来​​处理每次调用的返回。可以使用IDataErrorInfo完成有状态验证，其中您使用可以表示无效状态的中间类，但只允许对已验证的更改进行提交。这允许您自由地操纵对象，但也向用户提供关于其状态有效性的反馈。带有错误代码的等效逻辑通常需要为每次使用都使用switch语句。

Answer 3

1000并不多，您应该确保底层整数类型足够大（不要对char使用enum。

第二个想法，如果您手动输入1000，那么1000吨，如果它们是从某些数据集生成的，那么它可能有点意义......

Answer 4

我完全同意duffymo。从y设计的角度来看，具有1000+值的枚举闻起来很糟糕。更不用说开发人员在这样的GOD ENUM上使用情报会非常讨厌:-) 我最好去使用资源。

Answer 5

我认为这是非常糟糕的，对于错误处理，你可以简单地使用资源，因为我看到你想做反思并且获取描述也很糟糕。 如果您不想使用资源，则可以为每个业务规则定义不同的enum，并且您的不同业务不需要其他错误消息（并且不应该像这样）。