代码之家 › 专栏 › 技术社区 › sohtimsso1970

有很多枚举值有什么坏处吗?(许多>=1000)

integer enums .net c#

5

sohtimsso1970 · 技术社区 · 15 年前

我有一大串错误消息,我的biz代码可以根据输入的内容返回。这份名单最终可能会超过一千份。

我想把这些都列举出来,使用[描述(“”)属性来记录友好消息。

比如:

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,并且必须返回一个表示错误的整数值列表。我不认为资源允许你用一个整数来表示一个资源值。我错了吗?

b)无国产化要求。

5 回复 | 直到 15 年前

1

7

duffymo 15 年前

我认为一个枚举中有1000多个值的设计需要更多的考虑。听起来像是一个“上帝枚举”的反模式必须为这个案件而发明。

2

4

Dan Bryant 15 年前

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

枚举本身不应该是一个问题,尽管将所有错误代码放在一个主列表中可能会造成混淆。您可以考虑为返回代码的单独类别创建单独的枚举,因为这将使开发人员更容易理解特定函数的可能返回值。如果代码是唯一的很重要,您仍然可以为它们提供不同的数值(通过显式指定数值)。

另一方面,在现代.NET开发中,.NET BCL没有太多地使用返回代码,因此在某种程度上不鼓励使用返回代码。它们会产生可维护性问题(您几乎无法删除旧的返回代码或可能破坏向后兼容性),并且它们需要特殊的验证逻辑来处理每个调用的返回。状态验证可以通过 IDataErrorInfo ,其中使用可以表示无效状态的中间类,但只允许提交已验证的更改。这允许您自由地操作对象,但也可以向用户提供关于其状态有效性的反馈。带有错误代码的等效逻辑通常需要每次使用一个switch语句。

3

2

Motti 15 年前

1000不多,您应该确保基础整数类型足够大(不要使用 char 为了你的 enum .

第二种想法是1000吨如果你手动输入它们,如果它们是从一些数据集生成的,这可能有点道理…

4

1

user407665 15 年前

我完全同意达菲莫的观点。从y设计的角度来看,一个具有1000+值的枚举闻起来很糟糕。更不用说开发人员在这样一个上帝的枚举上使用智能是非常讨厌的:—) 我最好去使用资源。

5

0

Saeed Amiri 15 年前

我认为这是非常糟糕的,因为错误处理可以简单地使用资源,正如我看到的,您希望进行反射并获取描述,这也是很糟糕的。如果不想使用资源,可以定义不同的 enum 对于您的每个业务规则,您的不同业务也不需要其他错误消息(并且不应该是这样)。