Хранить иерархические данные Const

Question

Я часто задавался вопросом о правильном способе сделать это:

Например, в моей программе у меня есть около 100 констант (или перечислений), которые используются в некоторых вычислениях.Их желательно хранить в одном месте.Они могут быть сгруппированы иерархически, например:

System3 / Rules / Rule7 / ParameterXY / MaxAverageValue

Естественно, я хочу, чтобы эти значения были доступны во время кодирования, поэтому сохранение их в каком-либо ресурсе на самом деле не вариант.

Насколько я могу судить, это можно сделать с помощью:

• очень длинных имен констант
• классов вложенности
• пространств имен

Использование имен довольно некрасиво, и это не очень хорошо обслуживаемо.Я считаю, что вложенные классы - хороший способ сделать это, но некоторые правила stylecop / fxcop запрещают это, так что это должно быть «плохо» в некотором смысле.Наконец, я нахожу предложенную альтернативу, использующую пространства имен, не очень приятную.Imho создает массу папок и файлов, каждый из которых почти ничего не содержит.И мне не нравится, когда в отражателе сборки появляется 50 подпространств имен.

Итак ... как вы решаете такие задачи?Что бы вы предложили?

Answer 1

очень длинные имена констант

Это грубая разновидность, но, по крайней мере, ее можно обнаружить.Весь ваш код будет находиться в одном и том же месте, поэтому у вас не будет проблем с его поиском.

Я считаю, что вложенные классы - хороший способ сделать это, но некоторые правила stylecop / fxcop запрещают это, поэтомув некотором смысле это должно быть "плохо"

Одна из причин, по которой это плохо, заключается в том, что с инструментами автоматической генерации кода / проверки кода сложнее работать.Другая причина в том, что их труднее обнаружить с помощью Intellisense.

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

Пространства имен

Для описанной вами проблемы это лучший способ ее решить.Вы получаете наименьший беспорядок на уровне, и вы получаете Intellisense при наборе текста, чтобы вы могли видеть, к чему вы сужаетесь, спускаясь по иерархии.

Имхо, он создает массу папок и файлов, которыекаждый из них почти ничего не содержит

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

Еще одно предложение

Есть ли у вас домен-специфичные объекты, к которым вместо этого относятся эти константы?Например, есть ли логика, связанная с классом System3 / Rules / Rule7?Разве это не какое-то действительное бизнес-правило, которое вы должны воплотить в своем собственном классе?

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

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

Answer 2

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

Если вам просто нужно хорошее место, чтобы просмотреть их все в одном месте, вы также можете посмотретьпри сохранении их в файле app.config, и вы можете получить к ним доступ через AppSettings и класс ConfigurationManager.

Answer 3

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

Ключи в нашем файле ресурсов разделены знаком '.' построить иерархию.

Мы можем иметь отдельные файлы ресурсов, которые скомпилированы в одну иерархию классов.

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

Answer 4

Что ж, я так и делаю, чтобы получить запечатанный файл с именем Constants.

, поэтому

public sealed class Constants
{

  //for e.g.
  //Sessions
  public const string APPSESSIONKEY = "AppType";

}

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

Позвонив в коде.

Constants.AppSessionKey

Вы также можете

Создайте сборку, единственной целью которой является сохранение постоянных значений для проекта.Затем каждая другая Ассамблея должна ссылаться на эту.После DRY и KISS, поскольку добавить ссылки достаточно просто.Основная проблема здесь - перекомпиляция.