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

В таких ситуациях используется ленивая инициализация, и ее также можно применить к DI, см. => Ленивая инициализация

Что делать, если вы хотите использовать экземпляр класса только в определенном метод вашего текущего? Вы должны вводить его для весь класс, тратя производительность на потенциально тяжелые экземпляры когда это не нужно?

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

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

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

Если вам нужно будет затем внедрить этот объект для вызова метода, разве инъекция по-прежнему не происходит для всего TestClass?

При внедрении зависимости в класс в ASP.NET Core внедрение происходит на уровне класса, то есть зависимость доступна для всех методов внутри этого класса. Однако это не обязательно означает, что зависимость создается немедленно или что она оказывает сильное влияние на производительность.

Какой здесь лучший подход? Является ли ответ действительно инъекционным? весь класс? Что, если внутренний класс является помощником ORM, нужно ли мне каждый раз создавать соединение с БД?

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

Если вы предпочитаете отложенную инициализацию, она откладывает создание экземпляра до первого доступа к нему. В этом случае вы можете сделать что-то вроде ниже:

public class TestClass
{
    private readonly ILogger<TestClass> _logger;
    private readonly Lazy<InnerClass> _innerClass;

    public TestClass(ILogger<TestClass> logger, IServiceProvider serviceProvider)
    {
        _logger = logger;
        _innerClass = new Lazy<InnerClass>(() =>
            new InnerClass(serviceProvider.GetRequiredService<ILogger<InnerClass>>()));
    }

    private void CallSomethingFromInnerClass()
    {
        _innerClass.Value.DoInnerClassWork();
    }
}

Кроме того, для помощников ORM, таких как DbContext, Entity Framework Core эффективно управляет соединениями посредством пула соединений. Внедрение DbContext в ваши службы обычно эффективно, поскольку оно не создает каждый раз новое соединение с базой данных, а повторно использует существующие соединения из пула.

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

Примечание. Если у вас есть время, я бы рекомендовал вам проверить этот официальный документ.

Но что, если вы хотите использовать экземпляр класса только в определенном методе вашего текущего? Вы должны внедрить его для всего класса, тратя производительность на потенциально тяжелые экземпляры, когда в этом нет необходимости?

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

Откладывание инициализации означает, например, подключение к базе данных не внутри конструктора, а при первом использовании класса. Например, такие O/RM, как Entity Framework, используют этот подход. Только при вызове любого из свойств DbSet будут установлены соединения с базой данных. Введение неиспользованного DbContext довольно легко.

Тем не менее, графы объектов, состоящие из тысяч экземпляров, по-прежнему могут вызывать проблемы с производительностью. Однако мой опыт показывает, что очень большие графы объектов существуют только в тех графах объектов, к классам которых применяется запах кода Over-Injection конструктора. Другими словами, занятия, нарушающие Принцип единой ответственности.

Помимо уменьшения количества зависимостей класса, обычно более быстрым решением (или обходным путем) является увеличение срока существования зависимостей. Например, от Transient к Scoped. Это кэширует компонент со всеми его созданными зависимостями и может значительно сократить количество создаваемых объектов в графе объектов.

У меня есть класс, который имеет множество методов, каждый из которых делает свое дело.

Если методы имеют низкую связность, это указывает на нарушение принципа единой ответственности.

Предположим, что класс нельзя разделить на разные более мелкие классы, возможно, это контроллер.

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