Как правило, DI накладывает накладные расходы на ваше приложение, как и любой другой компонент, такой как инфраструктура MVC или ORM. Сколько зависит от нескольких вещей, таких как структура DI, тип внедрения и нагрузка на вашу платформу. Здесь вы можете найти тесты многих DI-фреймворков . На 500 000 инъекций вы увидите задержку в несколько секунд в худшем случае.
Поймите, что и почему вы оптимизируете
Как правило, вы должны знать, что вы хотите архивировать (например, время загрузки страницы <1 сек). Или какую проблему нужно решить. Например, вы должны по-разному заботиться о производительности при разработке для 100 000 пользователей в день, где это не менее важно только для 500 пользователей в день. Это будет более сфокусировано на бэкэнде, где вы сможете сэкономить на стоимости сервера при размещении большого приложения. </p>
Оптимизируй свой код
Если вы чувствуете необходимость оптимизации, сначала подумайте о том, где было бы полезно оптимизировать. На DI вы получаете доход, используя его. Вы можете считать это лучшей практикой, поскольку она подготавливает ваше приложение к автоматическим тестам. Поэтому я бы рекомендовал сначала проверить, можете ли вы оптимизировать другие части приложения.
Ваш код уже показывает типичную ошибку:
@if (post.GetAll().Any())
{
// Some code here...
}
Кажется, что PostServices.GetAll делает что-то вроде:
dbContext.Posts.ToList();
, что приводит к запросу SELECT * FROM Posts. Другими словами: вы выбираете все данные таблицы записей, чтобы определить, есть ли какие-либо из них внутри. По мере роста этой таблицы это приведет к значительным накладным расходам (представьте, что эта часть извлекает 100, 1000, 10.000 или более наборов данных).
База данных может сделать это намного эффективнее! Просто используйте dbContext.Posts.Any(), чтобы сама БД проверила наличие данных, не возвращая потенциально большой набор необязательных данных.
Это всего лишь пример, есть гораздо больше способов поддерживать производительность запросов EF, например, использовать запросы только для чтения (что позволяет избежать затрат на отслеживание изменений EF). Вы можете найти несколько примеров здесь , но вы можете свободно искать на SO или других сайтах производительность .NET Core / EF.
Оптимизируйте ваше веб-приложение
Не просто сосредоточьтесь на скорости бэкенда! Сегодняшние веб-приложения содержат кучу CSS, а также JavaScript. Это может оказать большое влияние на воспринимаемое время загрузки для ваших пользователей. Ваш сервер может отобразить страницу в <100 мс. Но когда браузеру нужно загрузить несколько МБ CSS с блокировкой JS, посетитель будет медленно чувствовать вашу страницу. </p>
Вы должны подумать о том, что действительно необходимо, использовать пакеты, такие как gulp или webpack, и оптимизировать эти файлы, используя minifying / uglyfing. Также рекомендуется загружать css в голову и js в нижний колонтитул. Это позволит избежать блокирования эффектов с помощью js, и ваш посетитель будет чувствовать вашу страницу быстрее, так как css загрузился первым ~> Они увидят страницу, где js можно скачать и отобразить чуть позже.
Выбор компонентов / библиотек по производительности
Это уже позволяет хорошо выполнять приложения в ASP.NET Core. Но если вам этого недостаточно, есть еще способы оптимизировать. Посмотрев на тесты вы увидите, что ASP.NET Core сам по себе является быстрым каркасом. В настоящее время занимает # 6 с ~ 294 000 запросов в секунду. Обратите внимание, что это достигается без какой-либо технологии MVC или ORM. С EF вы достигаете около 88.000 оборотов в секунду.
Реалистичный винт, который можно настроить, это ваш ORM. Например, см. Dapper , простой объектный картограф, разработанный командой стекового потока. Это не полный ORM, такой как EF, который генерирует ваши SQL-запросы, но его основной функцией является сопоставление результата базы данных с объектом вашей сущности. Как вы можете видеть в тестах производительности, это намного быстрее, чем EntityFramework.
Вы должны решить для себя, стоит ли это для вашего заявления. Это делает приложение легче, но вам нужно заботиться о SQL-запросах. И было бы не так просто перейти к другому поставщику базы данных, например. Это зависит от ваших требований: большой сайт, такой как SO, может ускорить процесс и сохранить ресурсы, тогда как небольшие проекты могут даже не заметить разницу.