Лучшие практики для использования и сохранения перечислений

Хранение текстового значения enum в базе данных менее предпочтительно, чем хранение целого числа, поскольку требуется дополнительное пространство и медленный поиск. Он ценен тем, что он имеет большее значение, чем число, однако база данных предназначена для хранения, а уровень представления предназначен для того, чтобы все выглядело хорошо.

Imho, что касается части кода:

Вы должны всегда использовать тип 'enum' для своих перечислений, в основном вы получаете много халявы если вы это сделаете: безопасность типов, инкапсуляция и предотвращение переключения, поддержка некоторых коллекций, таких как EnumSet и EnumMap , а также ясность кода.

Что касается части сохранения, вы всегда можете сохранить строковое представление перечисления и загрузить его обратно с помощью метода enum.valueOf (String).

Я согласен со многим из того, что вы говорите. Одна вещь, которую я хотел бы добавить, хотя, насчет сохранения перечислений: я не верю, что создание перечислений во время сборки из значений БД является приемлемым, но я также считаю, что проверка во время выполнения не является хорошим решением. Я бы определил третье средство: проведите модульный тест, который проверит значения перечисления в базе данных. Это предотвращает «случайное» расхождение и позволяет избежать затрат на проверку перечислений в базе данных при каждом запуске кода.

Начальная статья выглядит хорошо для меня. Тем не менее, основываясь на комментариях, кажется, что некоторые комментарии, касающиеся перечислений Java, могут прояснить несколько вещей.

Тип enum в Java является классом по определению, но многие программисты склонны забывать об этом, потому что они скорее связывают его со «списком допустимые значения "как в некоторых других языках. Это нечто большее.

Поэтому, чтобы избежать этих операторов switch, было бы разумно поместить некоторый код и дополнительные методы в класс enum. Почти никогда не нужно создавать отдельный «enum-like real class».

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

Если вы хотите представить значения перечисления как целые числа в базе данных из-за скорости или по любой другой причине, это отображение также должно находиться в перечислении Java. Вы получите отображение имени строки по умолчанию, и я доволен этим. Есть порядковый номер, связанный с каждым значением перечисления, но использование этого непосредственно в качестве отображения между кодом и базой данных не очень ярко, потому что этот порядковый номер изменится, если кто-то переупорядочит значения в исходном коде. Или добавляет дополнительные значения перечисления между существующими значениями. Или удаляет какое-то значение.

(Конечно, если кто-то изменит имя перечисления в исходном коде, сопоставление строк по умолчанию также станет плохим, но это менее вероятно произойдет случайно. И вы можете легче защититься от этого, если необходимо, поместив некоторые проверки времени выполнения и проверки ограничений в базу данных, как уже предлагалось здесь. )

В обработке кода для C # вы пропустили определение сброса значения 0. Я почти всегда объявляю свое первое значение как:

public enum SomeEnum
{
    None = 0,
}

, чтобы служить нулевым значением. Поскольку тип поддержки представляет собой целое число, а целое число по умолчанию равно 0, поэтому во многих местах очень полезно знать, действительно ли перечисление было установлено программно или нет.

Java or C# should always use enums in code. Disclaimer: My background is C#.

If the value is to be persisted to a database, the integral values of each enumeration member should be explicitly defined so that a later change in code does not accidentally alter translated enum values and thus application behavior.

Values should always be persisted to a database as integral values, to protect against enum name refactoring. Keep documentation on each enumeration in a wiki and add a comment to the database field pointing to the wiki page documenting the type. Also add XML documentation to the enum type containing a link to the wiki entry so that it is available through Intellisense.

If you use a tool to generate CRUD code it should be capable of defining an enumeration type to use for a column so that generated code objects always use enumerated members.

If custom logic needs to be applied for an enumeration member, you have some options:

• If you have an enum MyEnum, create a static class MyEnumInfo which offers utility methods to discover additional information about the enum member, by switch statements or whatever means necessary. Appending "Info" to the end of the enum name in the class name ensures that they will be next to each other in IntelliSense.
• Decorate the enumeration members with attributes to specify additional parameters. For example we have developed an EnumDropDown control which creates an ASP.NET dropdown filled with enumeration values, and an EnumDisplayAttribute specifies the nicely formatted display text to use for each member.

I have not tried this, but with SQL Server 2005 or later, you could theoretically register C# code with the database that would contain enum information and the ability to convert values to enums for use in views or other constructs, making a method of translating the data in a manner easier for DBAs to use.

Каждый раз, когда вы обнаруживаете, что используете «магические числа» в коде, меняйте его на enums. Помимо экономии времени (так как магия исчезнет, ​​когда появятся ошибки ...), она сохранит ваши глаза и память (значимые перечисления делают код более читабельным и самодокументируемым), так как угадайте, что - вы, скорее всего, человек, который должен поддерживать и развивать ваш собственный код

Ну, Исходя из моего опыта, использование перечислений для чего-либо, кроме передачи опций (в качестве флагов) в непосредственный вызов метода, приводит к тому, что в какой-то момент переключит -ing.

• Если вы собираетесь использовать все перечисления над вашим кодом вы можете получить код, который не так прост в обслуживании (печально известная инструкция switch )
• Расширение перечислений - это боль. Вы добавляете новый элемент enum и заканчиваете тем, что просматриваете весь свой код для проверки всех условий.
• В .NET 3.5 вы можете добавлять методы расширений в перечисления, чтобы они вели себя как классы. Однако добавить реальную функциональность таким способом не так просто, так как вам необходимо обеспечить правильную десериализацию в одноэлементные экземпляры.