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

StackOverflow https://stackoverflow.com/questions/606649

  •  03-07-2019
  •  | 
  •  

Вопрос

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

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

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

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

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

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

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

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

Спасибо!

Это было полезно?

Решение

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

Другие советы

Этот метод кажется мне вполне приемлемым.

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

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

enum status
{
    Active,
    Deleted,
    Inactive
}

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

ID   Имя
0 Активных
1 Исключен
2 Неактивных

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

Да, это прекрасно!

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

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

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

  NULL = 0

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

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

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

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

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

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

Чтобы прямо ответить на ваш вопрос, это очень верный подход.

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

Отбросьте идентификатор и просто явно задайте идентификаторы значений подстановки.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top