Лучший шаблон дизайна для объектов, где важно состояние - Singleton или Static

Question

Точнее говоря, каков наилучший подход для классов, где состояние имеет значение, в приложении, которое реализует внедрение зависимостей.

Скажем, мне нужен доступ к объекту, который находится в определенном состоянии. Например, этот объект мог быть инициирован в другом потоке или процессом, который я не могу контролировать.

Хорошим примером такого объекта, который уже существует в .NET, является HttpContext.

В этом случае Microsoft решила использовать статический подход, поэтому я просто говорю:

var currentObj = HttpContext.Current;

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

Проблема статического подхода заключается в том, что он не очень хорошо работает с внедрением зависимостей.

Другой вариант - настроить определенный класс как Singleton в вашем контейнере IoC. Это означает, что вы можете добавить его, и в зависимости от текущей конфигурации контейнера IoC это будет правильный экземпляр класса.

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

Итак, есть ли образец, который помогает мне здесь?

Контекст:

Для контекста я работаю над приложением, у которого есть много экземпляров класса, выполняющего операции ввода-вывода. Они существуют в своих собственных потоках.

Я хочу иметь возможность взаимодействовать с этими объектами (фоновыми задачами) через веб-интерфейс, то есть с контроллером. Я хочу иметь возможность допросить их, манипулировать ими и т. Д.

Обновление:

Извините, я думаю, что мое использование термина "с состоянием" немного вводит в заблуждение. позвольте мне объяснить кое-что:

1. «государство», вероятно, неправильное слово. Я имею в виду связь с объектом, в результате чего я не могу контролировать его жизненный цикл.
2. Забавно, что я использую «stateful», когда говорю о статических классах. Вот почему я привел пример HttpContext, как именно то, что он делает. Свойство Current дает вам очень конкретный экземпляр, а не новый экземпляр.
3. Когда я говорю, что static не работает с DI, я имею в виду, вы не можете вводить классы Static. Я мог бы создать оболочку, да, но я просто выдвигаю проблему в другом месте, нет?
4. Я должен был быть более четким в своем определении Синглтона. Я имел в виду образ жизни Singleton, как это определено в контейнере IoC.

Answer 1

Я всегда предпочитаю синглтон, а не статический. На самом деле я почти никогда не использую статику в своих классах.

Answer 2

Ни то, ни другое. Предполагая, что зависимость с состоянием является поточно-ориентированной, лучший подход состоит в том, чтобы построить хотя бы базовый уровень абстракции вокруг указанной зависимости, а затем внедрить указанную абстракцию в ваши классы. Синглтон против статики становится довольно несущественным.

Answer 3

Истинные синглтоны и статические классы очень сложны для написания автоматических тестов.Вы имеете в виду, что один экземпляр был найден во время выполнения?Это имело бы смысл для меня, но я не знаю правильную конструкцию для использования в C #.Аналогом в Java является JNDI.