Мнение о создании общего служебного статичного класса

Часть из того, что я читал об этом вчера и сегодня:

• (ТАКИМ ОБРАЗОМ), необходимо ли избежать статических классов?
• (ТАКИМ ОБРАЗОМ), когда использовать статические классы в C# - Mark S. Rasmussen делает хороший комментарий здесь
• Singleton по сравнению со статическим - Хорошая кавычка отсюда:

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

• Singleton, продуманный глупый
• (ТАК) Класс с отдельным методом — лучше всего приближаются? - Еще раз, кавычка от Mark S. Rasmussen:

  Требовательные потребители для создания экземпляра классов ни по какой причине; Истинные служебные классы, которые не представляют угрозы для чрезмерного увеличения размера, являются превосходными случаями для статических методов - Система. Преобразуйте как пример. Если Ваш проект является одноразовым без требований для будущего обслуживания, полная архитектура действительно не очень важна - статичный или не статичная, действительно не имеет значения - скорость разработки делает, как бы то ни было.

• (ТАК) Делая Методы Всеми Помехами в Классе - Скорость не является проблемой прямо сейчас для меня, код должен работать *ПРАВИЛЬНО* при вызове несколькими клиентами с веб-сайта и с (возможно, но вряд ли) несколько клиентов из приложения администрирования.

Мы (я), занятый, переписывая наших главных приложений в данный момент, и один из проектов в решении "Распространен", и это содержит единый класс, "clsCommon". Этот класс не имеет никаких свойств, единственный закрытый метод, который называют как единственная строка в конструкторе и затем просто открытых методах.

Этот класс обрабатывает вещи как (не реальные имена методов или подписи):

• Копирование файлов:
  • CopyFile
  • DecryptAndCopyFile
• Файл настроек XML:
  • GetSpecificXMLValue (запрашивает файл настроек XML для значения),
  • SetSpecificXMLValue
  • DeleteSpecificXMLValue
• Создание каталогов
• Получение меток времени как строки ('возвращают DateTime. Теперь. ToString ("yyyyMMddHHmmss")';)
• Различные строковые функции на переданных параметрах
• Выписывание к файлам журнала.
• Проверка параметра переданной строки, если это содержит только элементы в белом списке (белый список является частным Списком 'только для чтения', которому присваивают значение в конструкторе.)

В настоящее время все другие проекты в решении имеют ссылку на этот проект, и они обеспечивают доступ к классу:

namespace Us.OtherProjects
{
   public class clsCommon : Us.Common.clsCommon
   {}
}

namespace Us.OtherProjects
{
   public static class clsMain
   {
         public static clsCommon CommonClsClassReferenceForGlobalUsage = new clsCommon();
         .
         .
         .
   }
}

namespace Us.OtherProjects
{
   public class clsOtherClass
   {
      .
      .
      .
         private void someMethod()
         {
            string something = clsMain.CommonClsClassReferenceForGlobalUsage.Foo();
         }
      .
      .
      .
   }
}

Каковы Ваши мнения о создании этого класса статический класс или возможно одиночный элемент, как описано Jon Skeet здесь?