Является ли плохой практикой использование перечисления, которое отображается на некоторые начальные данные в базе данных?

Question

В моей базе данных есть таблица с именем "OrderItemType", в которой содержится около 5 записей для различных OrderItemTypes в моей системе. Каждый OrderItem содержит OrderItemType, и это дает мне ссылочную целостность. В моем промежуточном коде у меня также есть enum, который соответствует значениям в этой таблице, чтобы иметь бизнес-логику для разных типов.

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

Answer 1

Я делаю это все время и не вижу в этом ничего плохого. Дело в том, что существуют значения, которые являются особыми для вашего приложения, и ваш код должен по-разному реагировать на эти значения. Ваш менеджер предпочел бы, чтобы вы жестко закодировали Int или GUID для идентификации типа? Или он предпочел бы, чтобы вы извлекали специальный объект из OrderItem для каждого типа в базе данных? Оба сосут намного хуже, чем перечисление.

Answer 2

Еще один голос за вас, я также использую перечисление базы данных int <-> application enum, кроме того, я обычно описываю свои перечисления следующим образом:

public enum Operation
{
    [Description("Add item")]
    AddItem = 0,

    [Description("Remove item")]
    RemoveItem = 1
}

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

В коде вы можете просто добавить свойство, подобное этому:

public class Order
{
    public int OrderTypeInt;

    public OrderTypeEnum OrderType
    {
        get { return (OrderTypeEnum)OrderTypeInt; }
        set { OrderTypeInt = (int)value; }
    }
}

Answer 3

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

На самом деле все гораздо сложнее, чем кажется.

Вот ссылка на MSDN, чтобы объяснить, как динамически создавать перечисление.
http://msdn.microsoft.com/en-us/library/system.reflection.emit.enumbuilder.aspx

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

Answer 4

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

Answer 5

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

Причина такого подхода проста:

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

Answer 6

Мы тоже это делаем. В нашей базе данных есть столбец Int, который мы сопоставляем со значением Enum в коде.

Answer 7

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