Что не так с глобальным созданием экземпляров сервисов при запуске приложения вместо внедрения зависимостей Ninject?

В настоящее время я использую Ninject для обработки DI в приложении С#/.Net/MVC. Когда я отслеживаю создание экземпляров своих сервисов, я обнаруживаю, что сервисы вызываются и создаются довольно часто в течение жизненного цикла, поэтому мне приходится создавать экземпляры сервисов и кэшировать их, а затем проверять кэшированные сервисы, прежде чем создавать экземпляры других. Конструкторы иногда довольно тяжелые).

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

То, что я сделал в качестве быстрой альтернативы (просто для проверки концепции на данный момент, чтобы увидеть, работает ли она вообще), это...

• Создал статический класс (называемый AppServices) со всеми моими сервисными интерфейсами в качестве его свойств.
• Учитывая этот класс, метод Init(), который создает прямую реализацию каждого интерфейса службы из моей библиотеки служб. Это имитирует привязку их к ядру, если бы я использовал Ninject (или другой обработчик DI).

E.g.

public static class AppServices(){
  public IMyService MyService;
  public IMyOtherService MyOtherService;

  public Init(){
     MyService = new MyLib.MyService();
     MyOtherService =  new MyLib.MyOtherService();
  }
}

• В App_Start я вызываю метод Init() для создания списка глобально доступных служб, экземпляры которых создаются только один раз.
• С тех пор каждый раз, когда мне нужен экземпляр службы, я получаю его от AppServices. Таким образом, мне не нужно продолжать создавать новые экземпляры, которые мне не нужны.

E.g.

var IMyService _myService = AppServices.MyService;

Это отлично работает, и у меня пока не возникало НИКАКИХ проблем. Моя проблема в том, что это кажется слишком простым. Это всего лишь несколько строк кода, создающих статический класс в области приложения. Поскольку он делает именно то, что мне нужно для Ninject, но (как мне кажется, для моих целей) намного чище и экономит производительность, зачем мне нужен Ninject? Я имею в виду эти сложные обработчики внедрения зависимостей создаются не просто так? Должно быть что-то не так с моей «простой» интерпретацией DI, я просто не вижу этого.

Может ли кто-нибудь сказать мне, почему создание глобального статического контейнера для моих экземпляров службы - плохая идея, и, возможно, объяснить, почему именно Ninject (или любой другой обработчик DI) так необходим. Я понимаю концепции DI, поэтому, пожалуйста, не пытайтесь объяснить, что делает его таким замечательным. Я знаю. Я хочу точно знать, что он делает под капотом, что так отличается от моего метода App_Start.

Спасибо