Используете ли вы перечисления в ваших приложениях данных и как?

Question

Моя практика показывает, что общее корпоративное приложение имеет много сущностей, природа которых соответствует элементарному перечислению. Например, у нас может быть сущность Order, которая может иметь такие поля, как «OrderType», «OrderStatus», «Currency» и т. Д., Ссылаясь на соответствующие сущности, которые представляют собой не что иное, как текстовое имя, связанное с ключом, на который делается ссылка. *

Использование перечислений будет выглядеть очень естественно здесь. Но сущности должны быть определены в коде приложения во время разработки, я прав? В то время как мы должны иметь возможность CRUD варианты значений перечисления во время выполнения и использовать перечисления в SQL-запросах на стороне сервера (например, хранимые процедуры и представления).

Какие у вас практики и мысли на эту тему?

Меня особенно интересуют C # 4, linq и T-SQL.

Answer 1

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

В ситуациях, когда я собираюсь имитировать значение базы данных с помощью перечисления, я использую имя перечисляемого значения в качестве первичного ключа таблицы и в качестве значения, передаваемого во внешний ключ. То есть, когда я сохраняю в базу данных, я собираюсь передать myEnumVal.ToString(). У меня есть несколько причин для этого. Во-первых, требуется, чтобы добавление значения было более осознанным. Если бы я использовал числовое значение в качестве первичного ключа, это означало бы, что я использую суррогатный ключ и что дополнительные значения могут быть легко добавлены. Когда другие разработчики видят столбец, используя имя в качестве первичного ключа, есть большая вероятность, что они будут думать, что значение не является произвольным. Во-вторых, это значительно облегчает чтение кода базы данных. Вы получаете запросы типа Where OrderStatus = 'Active' вместо Where OrderStatus = 1.

Answer 2

В некотором смысле перечисления C # похожи на объектно-ориентированную иерархию классов.Если вы объявляете перечисление Choice с альтернативами One и Two, это немного похоже на объявление иерархии классов с базовым классом Choice и двумя производными типами (One : Choice и Two : Choice).

• Одно отличие состоит в том, что перечисления не являются расширяемыми (если вам нужно добавить регистр, вам нужно изменить объявление, а если вам нужно добавить регистр в иерархию классов, вы просто определяетеновый унаследованный тип).

• Второе отличие состоит в том, что параметры перечисления не могут переносить дополнительные данные - если вы объявляете иерархию классов, вы можете хранить другие поля в случае One (например).

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

Однако, поскольку перечисления C # очень просты, они в основном используются для представления значений indв зависимости от конкретной области или значений, которые необходимы более широко в программировании.Например:

enum TriState { True, False, Undecided }

Это может быть весьма полезным типом, но он не имеет прямого отношения к какому-либо конкретному домену.