Использование Enum для «статуса» объекта уровня данных в C #

Question

У меня есть объект данных (скажем, он называется «Ввод»), который имеет набор потенциальных состояний, которые выглядят примерно так:

1 - Created
2 - File added
3 - Approved
4 - Invalid

Это представлено в базе данных с помощью таблицы «Status» с первичным ключом autonumber, а затем поля «StatusId» в основной таблице с установленными соответствующими отношениями.

В моем (пользовательском) слое данных у меня есть объект 'Entry', и в настоящее время я также объявляю Enum с указанными выше состояниями. Наконец, я объявляю частный экземпляр этого Enum вместе с соответствующим публичным свойством.

В моем методе Commit () я приводил экземпляр Enum к целому числу и передавал его в хранимую процедуру Update.

В моем статическом методе 'GetEntry ()' мне, очевидно, будет передано целое число из базы данных. Затем я использую метод Enum.Parse () для извлечения объекта, который является экземпляром моего Enum, который соответствует возвращаемому целому числу состояния. Я приведу это к типу моего Enum и назначу его локальной закрытой переменной.

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

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

Спасибо!

Answer 1

У нас есть что-то знакомое в одном из наших проектов. У нас есть таблица с типами предметов. Эти типы имеют идентификатор, в коде у нас есть перечисление с теми же идентификаторами. Дело в том, что в базе данных мы не используем autonumber (идентичность), поэтому у нас есть полный контроль над id. И при сохранении нашего объекта мы просто берем идентификатор перечисления, чтобы сохранить объект. Я также думал, что такой подход был грязным, но в конце концов он не так уж и плох.

Answer 2

Да, это хорошо!

ПОЖАЛУЙСТА, всегда явно устанавливайте такие значения. Таким образом, если кто-то когда-нибудь захочет добавить что-то, он поймет, что ценности важны, и с ним не следует путаться.

enum status
{
    Active = 1,
    Deleted = 2,
    Inactive = 3
}

Если вы передаете значение через WCF, я бы рекомендовал добавить

  NULL = 0

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

Answer 3

Мне кажется, что этот метод подходит.

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

например, если бы у меня было перечисление типа

enum status
{
    Active,
    Deleted,
    Inactive
}

У меня будет таблица с именем status, в которой будут следующие записи

Идентификационное имя
0 Актив
1 удалено
2 Неактивно

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

Answer 4

Если ваш код требует установки известных значений «Status» (которые вы определили в вашем перечислении), то, вероятно, также требуется, чтобы эти значения «Status» существовали в базе данных. Поскольку они должны существовать, вы также должны иметь контроль над Status_ID, назначенным каждому из этих значений.

Удалите идентификатор и просто явно установите идентификаторы значений для поиска.

Answer 5

Я делаю этот подход с Enums все время. Если это простой элемент, такой как статус, который, как ожидается, не изменится, я предпочитаю Enum. Синтаксический анализ и приведение в действие - очень низкая ударная операция.

Я успешно делал это с Linq to Sql уже некоторое время без проблем. Linq фактически конвертирует из Enum в int и обратно автоматически.

Код - это больше, чем просто скорость, но удобочитаемость. Перечисления делают код читабельным.

Чтобы ответить на ваш вопрос напрямую, это очень верный помощник.

Answer 6

необходима таблица поиска в базе данных; перечисление программ удобно, чтобы в коде не было «магических чисел»

если вашему коду не нужно манипулировать статусом, тогда перечисление не нужно