有很多枚舉值會有什麼危害嗎？（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）