Удержание экземпляра класса в статическом объекте в C#

Question

У нас есть класс "DataAccessServiceConnector", в котором у нас мало методов для связи со службой доступа к данным.

public class DataAccessServiceConnector: IDataAccessServiceConnector
{
     public async Task<HttpResponseMessage> GetDataAccessServiceResponse()
     {
        //Some code
        return GetDataFromDataAccessService();
     }        
}

У нас есть интерфейс:

public interface IDataAccessServiceConnector
{
    Task<HttpResponseMessage> GetDataAccessServiceResponse();
}

И имея другой класс, который содержит экземпляр класса "DataAccessServiceConnector" в качестве статического объекта.

public class ClassA
{
  public static IDataAccessServiceConnector DataAccessConnector;
  //Constructor of the Class
  ClassA()
  {
     DataAccessConnector = DataAccessConnector ?? new DataAccessServiceConnector();
  }
}

Это плохая практика для хранения экземпляра класса (например, DataAccessServiceConnector) в статическом объекте (например, DataAccessConnector)?

Answer 1

Опция 1.

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

Вариант 2

Предоставьте статический доступ к объекту экземпляра из объекта экземпляра в виде статического метода / поля / свойства.

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

Answer 2

Я думаю, что ответ на ваш вопрос основан на мнении в контексте Stackru.

Это классика "Является ли Singleton Pattern Bad?" вопрос:

• 180k + просмотров вопроса на SoftwareEngineering.SE;
• 390k + просмотр вопроса о самом Stackru;
• полный интернет из других источников.

---

В частности, существует множество проблем с Singletons и с памятью с общим доступом для записи в целом.

• Как уже упоминалось выше, совместное использование ресурсов требует крайней осторожности;
• Точно так же тестирование [юнитов] такого класса не просто;
• (Меж) зависимости между классами менее обнаружимы;
• Код сложнее следовать;
• Ошибки труднее исправить;
• Рефакторинг кода становится сложнее в определенных случаях;
• ... этот список можно продолжать и продолжать.

---

Я лично решил использовать Singletons только в качестве крайней меры. Даже в этом случае я бы полагался на одноэлементную регистрацию среды внедрения зависимостей вместо static поле. (Например , регистрация Singletonjector синглтон.)

Но прежде чем регистрировать что-то как Singleton, пожалуйста, сначала пересмотрите использование обычных объектов.