有很多枚举值会有什么危害吗？（many> = 1000）

我有一大堆错误消息，我的biz代码可以根据输入内容返回。这份名单最终可能会有一千多个。有很多枚举值会有什么危害吗？（many> = 1000）

我想只枚举这些，使用[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有很多值时，它们会关心枚举类型吗？

更新

我之所以不想用资源是因为

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

b）没有本地化要求。

来源

2010-10-31 sohtimsso1970

大会元数据往往被限制为每个分组65535组不同的元素。 – 2010-10-31 19:35:01

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

关于第二个想法是1000万吨，如果你手动输入如果他们是从一些数据生成的一组它可以使感有点...

来源

2010-10-31 18:53:26 Motti

我觉得有一个设计1,000+在枚举值需要一些更多的思考。听起来像一个“上帝枚举”反模式将有为这个案件发明

来源

2010-10-31 18:53:35 duffymo

我想过对模型使用通用的ErrorMessage类型，但似乎唯一的一点是有更少的垂直代码和更多的水平代码。我的计划是随着未来的需求变得更加清晰，更好地迭代更好的东西。 – sohtimsso1970 2010-10-31 18:59:12

虽然在一般情况下，我会说，这是不好的设计的征兆，我认为他有大约只有合法的情况下，它 - 必须为整数传递一个结果代码。 – 2010-10-31 19:17:10

我指出了友好的主要缺点在属性中定位是，如果您需要将您的应用本地化为其他语言，这将会带来挑战。如果这是一个考虑因素，将字符串放在资源文件中是一个好主意。

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

在一个侧面说明，在.NET BCL并没有太大的使用返回代码和返回代码在现代.NET开发有些气馁。他们创造可维护性的问题（你可以几乎从来没有删除旧的返回码或风险打破向后兼容性），他们需要特殊的验证逻辑来处理每一个电话的回报。有状态验证可以使用IDataErrorInfo完成，其中您使用可以表示无效状态的中间类，但只允许验证更改的提交。这使您可以自由地操作对象，还可以向用户提供有关其状态有效性的反馈。具有错误代码的等效逻辑通常需要每次使用的switch语句。

来源

2010-10-31 18:54:40

是的，我想到了本地化，但这不是必需的，而且极不可能。我想，如果这个要求出现了，我会让团队迭代到别的东西。 – sohtimsso1970 2010-10-31 18:57:13

关于在接口中使用有效/无效状态你有一个很好的观点，但我不同意使用返回类型是不鼓励的。这个ErrorMessage枚举不是唯一被返回的东西。它是结果模式的一部分，它允许biz图层返回许多不可能的任何其他方式的信息。（至少不是我能理解的）。请记住，这个biz层正在呈现各种控制器类型，包括REST和SOAP API。 – sohtimsso1970 2010-10-31 19:13:14

@ sohtimsso1970，这听起来像你的用例是一个例外，因为你需要打包更多的信息，而不仅仅是一个返回码。我更多地指的是使每个方法调用都返回一个整数的老派方法，以及用于解释每种方法结果的常量集合。在你的情况下，你需要支持多个服务前端，所以用于交流验证的错误代码可能是最好的。即使如此，将代码/结果分开也是有帮助的;我认为有一个中央“结果”会在稍后引起头痛。 – 2010-10-31 21:23:28

我完全同意duffymo。从设计的角度来看，1000+值的enum是不好的。更不用说，开发者在这样一个GOD ENUM上使用智能将是相当讨厌的:-)我最好去使用资源。

来源

2010-10-31 18:57:56

我不想使用资源的原因是因为我需要为每个错误返回一个唯一的整数值。 biz代码被用在不同的地方，包括一个API，所以有时我不能通过资源名称，但需要传递一个int。我将编辑问题以包含此内容。 – sohtimsso1970 2010-10-31 19:05:29

顺便说一句，您是否在运行时读出了[Description（“用户需要名字。”）]？这可能会影响性能。 – 2010-10-31 19:13:46

是的，有一点反射用于获取描述，但这只是每个应用程序实例发生一次，对吧？一旦获得该命中，应该不会再发生，除非应用程序重置。 – sohtimsso1970 2010-10-31 19:16:10

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

来源

2010-10-31 18:59:47

谁离开了一个downvote？请解释为什么？ – 2010-11-01 12:08:40

有很多枚举值会有什么危害吗？ （many> = 1000）

回答

相关问题

有很多枚举值会有什么危害吗？（many> = 1000）