Все зависит от того, что вы пытаетесь сделать с помощью enum.
Если вы пытаетесь помешать вашим разработчикам передавать магические числа в ваши операции, и вы хотите сохранить целостность ссылочной целостности данных в вашей БД, ДА! Используйте шаблоны T4 (используя ORM), чтобы перейти к таблице MeasurementUnitTypes и сгенерировать перечисление со столбцами ID, Name и Description, совпадающими с enum 'int, Enum_Name и Description Attribute (хороший подход для дополнительного поля \ data для перечисления @danijels) как предложено выше. Если вы добавите новый тип измерения в таблицу MeasurementUnitTypes, вы можете просто щелкнуть правой кнопкой мыши и запустить шаблон T4, и для этой новой строки, добавленной в таблицу, будет сгенерирован код перечисления. Мне не нравятся жестко закодированные данные в моем приложении, которые не связаны с моей БД, поэтому я упомянул подход T4-Template. В противном случае это не расширяется ... что если какая-то другая внешняя система захочет получить наши критерии измерения, используемые в нашей системе, то она жестко запрограммирована в системе, и вы не сможете предоставить ее клиенту через службу. Это осталось там.
Если цель не связана с данными, и у вас есть какая-то логика для определенного перечисления, тогда НЕТ! это нарушает SOLID (принцип Open close), как если бы вы где-то в вашем приложении применяли переключатель или связку If для действия логики на перечисление, ТАКЖЕ если вы сделали ДЕЙСТВИТЕЛЬНО плохо эти переключатели или Ifs повсюду в шоу .... удачи в добавлении нового enum ... так что он не открыт для расширения и закрыт для модификации, так как вам нужно изменить существующий код согласно принципу SOLID.
Если вы выбрали 2, тогда я предлагаю заменить ваше перечисление на следующее, используя пример из комментария @danijels:
public interface IMeasurementUnitType
{
int ID { get; }
string Description { get; }
// Just added to simulate a action needed in the system
string GetPrintMessage(int size);
}
Приведенный выше код определяет интерфейс (кодовый контракт), которому должно соответствовать каждое измерение. Теперь давайте определим процентное и пиксельное измерение:
public class PixelsMeasurementUnitType : IMeasurementUnitType
{
public int ID => 1;
public string Description => "Pixel";
public string GetPrintMessage(int size)
{
return $"This is a {Description} Measurement that is equal to {size} pixels of the total screen size";
}
}
public class PercentMeasurementUnitType : IMeasurementUnitType
{
public int ID => 2;
public string Description => "Persentage";
public string GetPrintMessage(int size)
{
return $"This is a {Description} Measurement that is equal to {size} persent of total screen size (100)";
}
}
Итак, мы определили два типа, мы будем использовать их в коде следующим образом:
var listOfMeasurmentTypes = AppDomain.CurrentDomain.GetAssemblies()
.SelectMany(s => s.GetTypes())
.Where(p => typeof(IMeasurementUnitType).IsAssignableFrom(p)
&& !p.IsInterface)
.ToList();
Здесь мы берем все ТИПЫ, которые расширяют интерфейс IMeasurementUnitType, а НЕ сам интерфейс. Теперь мы можем использовать Активатор для создания экземпляров классов для заполнения элементов управления нашего пользовательского интерфейса:
public IEnumerable<IMeasurementUnitType> GetInstantiatedClassesFromTypes(List<Type> types)
{
foreach (var type in types)
{
yield return (IMeasurementUnitType)Activator.CreateInstance(type);
}
}
Вы можете изменить приведенный выше код, чтобы он был универсальным для любого типа, И СЕЙЧАС наступает жизнь, и клиент задает новый тип единицы измерения, называемый Точка, как новое требование, мне не нужно ИЗМЕНИТЬ ЛЮБОЙ код, просто добавьте новый тип (расширить код НЕ изменять). Новый тип будет автоматически выбран в приложении.
public class PointMeasurementUnitType : IMeasurementUnitType
{
public int ID => 3;
public string Description => "Point";
public string GetPrintMessage(int size)
{
return $"This is a {Description} Measurement that is equal to {size} points of total screen size";
}
}
Хорошей идеей будет кэширование ваших типов для повышения производительности при запуске приложения или попытка использовать контейнер DI по вашему выбору.
Также можно утверждать, что где-то в вашем приложении вам нужно будет различать типы, и я согласен, однако вы хотите хранить яблоки с яблоками. Поэтому постарайтесь, насколько это возможно, применять тот же принцип, который используется для этих типов. Если этот тип используется в каком-либо классе графического процессора (например), тогда есть IGraphicsProcessor и ваши конкретные классы, которые различают эти типы, например PersentageAndPixelGraphicsProcessor (который расширяется от IGraphicsProcessor) или если он различает только один тип, вызовите его PersentageGraphicsProcessor.
Извините за ОГРОМНЫЙ SA, но мне действительно нравятся enum'ы, однако я чувствую, что когда вы пытаетесь отделить логику с помощью перечислений, это СИЛЬНЫЙ анти-паттерн.
комментарии приветствуются,