Какой срок внедрения зависимости должен быть предпочтительным?

Question

Для API REST, который не имеет зависимостей между запросами и использует ASP. NET Core DI.

Я слышал противоречивые аргументы при выборе наиболее подходящего:

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

Я понимаю, что они работают по-разному, но существует ли время жизни go -to? Должен ли он начинаться с «переходного процесса» и переходить к другим при необходимости?

Существуют ли какие-либо расследования, доказывающие, что время создания экземпляра, сэкономленное синглтоном, действительно имеет значение?

Answer 1

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

Я испробовал оба способа и в итоге обнаружил, что лучше начать с переходного процесса, а затем расширить область при необходимости.

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

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

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

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

Что касается производительности: я не проводил тестирование производительности с ASP. NET Базовая встроенная структура DI, но я обнаружил, что SimpleInjector достаточно быстр, поэтому затраты времени и памяти на создание новых экземпляров служб тривиальны по сравнению с другой работой, которую выполняет мое приложение (например, запросы к базам данных). .

Что касается предотвращения открытия нескольких соединений: SQL Соединения с сервером автоматически объединяются , поэтому стоимость создания new SqlConnection() и его размещения несколько раз в запросе обычно довольно тривиальна. .

Answer 2

Должен ли он начинаться с 'переходного процесса' и переходить к другим, как требуется?

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