Есть ли вред в том, чтобы иметь много значений enum? (много> = 1000)

Question

У меня есть большой список сообщений об ошибках, которые мой код BIZ может вернуть в зависимости от введенного. Список может закончиться с более чем тысячей.

Я хотел бы просто перечислить их все, используя атрибут [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 заботится о типах enum, когда они имеют много значений?

Обновление

Причина, по которой я не хотел использовать ресурсы, заключается в том, что

а) Мне нужно иметь возможность ссылаться на каждое уникальное сообщение об ошибке целочисленным значением. Уровень biz обслуживает API, в дополнение к другим вещам, и должен быть возвращен список целочисленных значений, обозначающих ошибки. Я не верю, что Ресурсы позволяют вам указывать значение ресурса целым числом. Я не прав?

б) Нет требований по локализации.

Answer 1

Я думаю, что дизайн, имеющий более 1000 значений в перечислении, нуждается в доработкеПохоже, что для этого случая нужно придумать анти-паттерн "God Enum".

Answer 2

Основным недостатком, который я хотел бы отметить, имея понятное описание в атрибуте, является то, что это вызовет проблемы, если вам когда-нибудь понадобится локализовать ваше приложение для другого языка. Если это соображение, было бы неплохо поместить строки в файл ресурсов.

Сам по себе enum не должен быть проблемой, хотя наличие всех ваших кодов ошибок в одном основном списке может сбить с толку. Вы можете рассмотреть возможность создания отдельных перечислений для отдельных категорий кодов возврата, так как это облегчит разработчикам понимание возможных значений возврата для конкретной функции. Вы по-прежнему можете давать им различные числовые значения (указав числовые значения явно), если важно, чтобы коды были уникальными.

Кроме того, в .NET BCL не очень часто используются коды возврата, а коды возврата несколько отговаривают в современной разработке .NET. Они создают проблемы сопровождения (вы почти никогда не можете удалить старые коды возврата или рискует нарушить обратную совместимость), и им требуется специальная логика проверки для обработки возвратов для каждого вызова. Проверка с сохранением состояния может быть выполнена с помощью IDataErrorInfo , где вы используете промежуточный класс, который может представлять недопустимые состояния, но который допускает только фиксацию проверенных изменений. Это позволяет вам свободно манипулировать объектом, а также обеспечивать обратную связь с пользователем относительно достоверности его состояния. Эквивалентная логика с кодами ошибок часто требует оператора switch для каждого использования.

Answer 3

1000 - это не много, вы просто должны убедиться, что базовый целочисленный тип достаточно большой (не используйте char для вашего enum.

Во-вторых, 1000 тонн, если вывводите их вручную, если они сгенерированы из некоторого набора данных, это может иметь смысл ...

Answer 4

Я полностью согласен с Даффимо. Перечень с 1000+ значениями плохо пахнет с точки зрения дизайна. Не говоря уже о том, что для разработчика было бы весьма неприятно использовать интеллект на таком БОГЕ ENUM :-) Я бы лучше пошел на использование ресурсов.

Answer 5

Я думаю, что это очень плохо, для обработки ошибок вы можете просто использовать ресурс, так как я вижу, что вы хотите сделать отражение и получить описание тоже плохо. Если вы не хотите использовать ресурсы, вы можете определить разные enum для каждого из ваших бизнес-правил. Также вашему бизнесу не нужны сообщения об ошибках других (и не должны быть такими). ​​