Перечисления или таблицы?
Я делаю это общественной Wiki, поскольку я ценил бы подход людей и не обязательно ответ.
Я нахожусь в ситуации, где у меня есть много полей данных типа поиска, которые не изменяются. Пример был бы:
Ежегодная зарплата
Опция: 0 - 25K
Опция: 25K - 100K
Опция: 100K +
Я хотел бы иметь эти опции, легко доступные через перечисление, но также хотел бы к текстовым значениям, доступным в DB, поскольку я сделаю создание отчетов о текстовых значениях и не идентификаторе. Кроме того, так как они статичны, я не хочу выполнять вызовы к DB.
Я думал, копируя это в перечислении и таблице, но хотел бы услышать некоторые альтернативные мысли.
Спасибо
7 ответов
Я думаю, что перепись - плохая идея. Просто учитывая тип данных, которые вы показываете, они могут измениться. Лучше иметь таблицу базы данных с полями ID/Min/Max/Description, которые вы загружаете при инициализации приложения
.Так как C# не разрешает Enum со строковыми значениями, я бы предложил структуру со статическими строками.
Таким образом, вы поддерживаете некоторую интеллектуальность, но без попыток получить значение Enum о том, что является строковым значением в БД.
Другое решение, которое я бы предложил: удалить логику, которая зависит от этих значений, и перейти к табличной логике. (Например, если в каждой трассе есть своя налоговая ставка, добавьте налоговую ставку как столбец в базе данных, а не случай {} в коде.)
.Использовать как enum(для кода), так и тексты БД- для представления графического интерфейса.
Итак, если у вас всегда будет 3 варианта использования перечисления LowSalary, MiddleSalary и HighSalary, сохраняйте свои тексты в БД и переключайте свои тексты в графическом интерфейсе, соответствующем значению вашего имущественного перечисления.
Я использую оба. В Linq to SQL и EF, вы просто делаете свойство столбца типом перечисления. В других фреймворках обычно можно как-то привязать колонку к свойству enum. Вы все еще можете иметь таблицу первичных ключей в БД, содержащую действительные перечисления.
Вы также можете сделать это с ограничением CHECK в БД, но это имеет тенденцию привязывать ваши данные к вашему приложению - кто-то, глядя только на БД, не обязательно будет знать, что означает каждое значение. Поэтому я предпочитаю гибридную таблицу/значение
.Сначала убедитесь, что эти данные действительно статичны. Если что-то изменится, вам придется перекомпилировать и переустановить.
Если данные действительно статические, я бы поехал по enum-маршруту. Можно создать YearlySalaryEnum, содержащий все значения. Для представления строки я бы использовал словарь со строковыми значениями и YearlySalaryEnum в качестве ключа. Словарь можно держать как статический экземпляр в статическом классе. Использовать его можно следующим образом (C#):
string highSalary = StaticValues.Salaries[YearlySalaryEnum.High];
Один из способов - это написать форматировщик, который может превратить перечисление в строковое представление:
public class SalaryFormatter : IFormatProvider, ICustomFormatter
{
public object GetFormat(Type formatType)
{
return (formatType == typeof(ICustomFormatter)) ? new
SalaryFormatter () : null;
}
public string Format(string format, object o, IFormatProvider formatProvider)
{
if (o.GetType().Equals(typeof(Salary)))
{
return o.ToString();
Salary salary = (Salary)o;
switch (salary)
{
case Salary.Low:
return "0 - 25K";
case Salary.Mid:
return "25K - 100K";
case Salary.High:
return "100K+";
default:
return salary.ToString();
}
}
return o.ToString();
}
}
Вы используете форматировщик, как и любой другой:
Console.WriteLine(String.Format(new SalaryFormatter(), "Salary: {0}", salary));
Форматировщик может быть расширен для поддержки различных форматов с помощью форматирования строк, множества типов, локализации и т.д.
.