Как избежать жесткого кодирования строк - PullRequest
6 голосов
/ 17 июля 2011

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

  • с использованием ресурсов .resx файлов
  • , хранящих эти значения и строки в App.config или web.config
  • создание статического класса ApplicationStrings и объявление всех содержащихся в нем строк и значений:

    public static class ApplicationStrings
    {
        #region constants
        public const string APPLICATION_NAME = "X";
        public const string APPLICATION_RESOURCEMANAGER_NAME = "ResourceManagerX";
        public const string APPLICATION_DEFAULT_LOGFILENAME = "log.txt";
    }
    

Однако не является ли 3-й метод простым жестким кодом?Имеет ли смысл иметь такой класс?Преимущество состоит в том, что все строки находятся в одном месте, но действительно ли это позволяет избежать жесткого кода?

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

Ответы [ 4 ]

5 голосов
/ 17 июля 2011

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

И тогда с файлами ресурсов есть преимущество i18n и l10n.Если вам это нужно, но многие крупные приложения должны.

1 голос
/ 17 июля 2011

По моему мнению, ApplicationSettings полезен только в том случае, если ваши настройки (i) действительно постоянны и (ii), конечно, действительно общедоступны.Если любой из этих случаев не соответствует действительности, то это не идеальный вариант, и вы вернулись к файлу .config .resx

1 голос
/ 17 июля 2011

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

0 голосов
/ 17 июля 2011

Ну, я думаю, что ApplicationStrings - это хорошее решение

...