Смешивание инъекций зависимостей с шаблоном проектирования Singleton - PullRequest
Новая
       67

Смешивание инъекций зависимостей с шаблоном проектирования Singleton

1 голос
/ 30 апреля 2020

У меня есть Singleton в моем проекте, который выглядит следующим образом: 

//Create a Singleton
static MySingleton Instance;
private static readonly object Padlock = new object();
/// <summary>
/// Singelton Method, to make sure only one instance of this class exists at runtime.
/// </summary>
/// <returns></returns>
public static MySingleton GetInstance()
{
  //Thread Safety
  lock (Padlock)
  {
    if (Instance == null)
    {
      Instance = new MySingleton();
    }
    return Instance;
  }
}

private MySingleton()
{
}

//[...]

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

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

IHelperClass Helper {get; set;}

IExectiveClass Executive {get; set;}

public NotMySingleton(IHelperclass helper, IExecutiveClass executive)
{
    Helper = helper;
    Executive = executive;
}

Но я понятия не имею, как объединить DependencyInjection с Singleton Pattern .

Есть ли способ использования Singletons с DependenyInjection? Что является обычной практикой? Какие альтернативы у меня есть (если это неподходящий вариант)

1 Ответ

2 голосов
/ 30 апреля 2020

Все инфраструктуры DI предоставляют способ определения времени жизни объектов, созданных контейнером DI. Одной областью действия обычно является Singleton.

Если вы позволите инфраструктуре DI управлять временем жизни вашей MySingleton, DI будет просто работать.

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

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

...