Производительность конструктора внедрения зависимостей - PullRequest
0 голосов
/ 13 февраля 2020

Моя команда рассматривает возможность перехода на внедрение зависимости от конструктора (ASP. NET Веб-API / Веб-формы с Autofa c и EF). Одна из самых больших проблем заключается в том, какой тип снижения производительности будет испытывать система ASP .NET / Autofa c, создающая / уничтожающая все объекты, необходимые для создания полной цепочки зависимостей - как минимум, каждый запрос будет создавать / dispose

  • контроллер
  • бизнес-логика c (кандидат-одиночка)
  • доступ к данным (кандидат-одиночка)
  • контекст модели EF

За исключением архитектурных соображений, фокусирующихся в основном на времени выполнения и использовании памяти, наблюдается заметное снижение производительности при построении / разрушении всего стека при каждом запросе , по сравнению с чем-то вроде решения бизнес-задач компоненты логики / доступа к данным для одноэлементных экземпляров? Я думаю, что при всей массе настройки конвейера запросов, контроллера и EF-контекста, добавление конструкции бизнес-логики / доступа к данным не принесет дополнительных затрат, но я хотел бы посмотреть, есть ли у сообщества опыт с этим сравнением, прежде чем мы попытаемся.

1 Ответ

0 голосов
/ 13 февраля 2020

есть ли заметное снижение производительности, возникающее при построении / разрушении всего стека каждый запрос 1005 * конструкция .

Каркас был разработан со встроенным DI.

Ссылка Внедрение зависимостей в ASP. NET Веб-API 2

Controllers и DbContext создаются для запроса HTTP. Все остальное, введенное в контроллер, будет зависеть от срока действия, используемого для его регистрации в контейнере. Transient, Singleton или Scoped.

В конструкторе не должно быть тяжелых действий.

Важно понимать, что при использовании Instructor Injection конструктор не должен содержать никаких дополнительных логик c.

Конструктор Injection не должен делать ничего, кроме получения зависимостей.

Ссылка Инъекторные конструкторы должны быть простыми

...