Правильный способ использования констант Globals

В почти каждом проекте я не могу решить, как бороться с определенными глобальными постоянными значениями. В более старые времена, когда я писал программы на С++, которые не использовали dll, это было легко. Просто создайте и .h файл с числом const, которое описывает определенные константные значения для моего проекта. Тогда у меня были все файлы, включая ta-da! Это сработало. Очистите, соблюдайте принцип DRY и прост.

Теперь мои проекты - С#.Net, что дает мне большой выбор возможностей для решения этой проблемы. Из того, что я знаю:

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

Итак, я знаю, что лучший способ сделать это объявление констант. Но я не знаю и до сих пор не смог найти, как это сделать. Не могли бы вы помочь? У меня есть конфеты!

Спасибо всем

Ответ 1

Если вы хотите, чтобы значения могли быть изменены во время выполнения, используйте app.config.

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

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

Ответ 2

Er, считая, что ваши константы не огромны, вы должны просто объявить их как public const в классе по вашему выбору:

namespace MyProject
{
    public class Awesome
    {
        public const int SomewhatAwesome = 1;
        public const int ExtraAwesome = 2;
        /* etc */
    }
}

Вы должны включать своих членов const в классы, к которым они относятся, т.е. если SomewhatAwesome и ExtraAwesome используются для класса Awesome и должны быть константами, объявленными в этом классе. Не создавайте дополнительную сборку только для хранения постоянных значений и не создавайте выделенный статический класс или пространство имен для своих констант, если нет ничего, что группирует константы вместе.

Файл app.config предназначен для параметров, которые могут быть изменены конечным пользователем во время выполнения. Не ставьте константы, которые не должны меняться в этом файле. Ресурсы предназначены для "больших" объектов, таких как текстовые файлы и изображения, которые были бы утомительными или невозможными для включения в качестве литеральных членов класса. Не ставьте простые вещи, такие как целые числа и короткие строки в ресурсах.

Ответ 3

Вместо const можно использовать ключевое слово readonly, чтобы не перекомпилировать все, когда значения меняются.

Выдержка из MSDN:

Хотя поле const является временем компиляции константа, поле readonly может быть используется для констант времени выполнения

Подробнее см. ссылку .

Ответ 4

Для проектов С#, если вы хотите константы, возможно, лучше всего использовать файл настроек, предоставленный в Visual Studio, в соответствии с вашими настройками проекта. Он поддерживает настраиваемые типы, а AFAIK - все, что помечено как сериализуемое.

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

Ответ 5

Похоже, что использование класса является рекомендацией Microsoft. http://msdn.microsoft.com/en-us/library/bb397677.aspx

Ответ 6

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

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

Ответ 7

У меня есть несколько проектов, над которыми я работал на работе, и мы решили создать статический класс для наших глобальных значений и функций:

namespace MyNamespace
{
    public static class MyGlobalClass
    {
        //Global stuff here
    }
}

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

Ответ 8

константы времени компиляции изменяются в зависимости от вселенной, в которой вы живете. Таким образом, pi и e являются константами времени компиляции.

константы времени выполнения могут потенциально меняться с каждой новой версией.

могут потенциально меняться каждое новое время, когда приложение запускается (или чаще в зависимости от того, как выполняются настройки, т.е. диск db, управляемый файл конфигурации и т.д.).

Ответ 9

Постарайтесь избегать классов Бога и статических "помощников", если вы можете им помочь. Вы должны стараться переместить постоянные данные в соответствующие классы.

Я предполагаю, что с тех пор, как вы используете С#, который вы хотите разработать, с соответствующими объектно-ориентированными проектами, принципами и шаблонами. Помните, что объекты касаются поведения - не обязательно функциональности. На мой взгляд, мышление функционально приводит к созданию процедурного кода.

Вы можете использовать шаблон Singleton, когда данные используются во многих объектах. Хотя, это не обязательно лучшая практика. В последнее время я начал использовать инъекцию зависимостей IoC больше в этих ситуациях с Unity и MEF.