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

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

0 голосов
/ 10 мая 2018

У нас есть класс " 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 )?

Ответы [ 2 ]

0 голосов
/ 10 мая 2018

Вариант 1.

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

Вариант 2.

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

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

0 голосов
/ 10 мая 2018

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

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

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

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

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

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

...