⚡ .NET 9 — самая быстрая платформа 2025 года
Microsoft прокачала .NET так, что он обгоняет почти все популярные фреймворки: Java, Go, Node.js, Python и даже PHP.
🚀 Что сделали:
- Мусорщик (GC) стал адаптивным → меньше пауз даже при высоких нагрузках.
- JIT-компилятор быстрее разогревает код и оптимизирует горячие участки.
- Векторизация через AVX10 и Arm SVE ускоряет циклы в несколько раз.
- Native AOT уменьшает размер бинарников и ускоряет запуск (контейнеры, IoT, edge).
- Сеть (сокеты, HTTP/3) стала работать быстрее с низкой задержкой.
- JSON обрабатывается через System.Text.Json максимально эффективно.
- Меньше аллокаций → меньше нагрузка на память и GC.
- Thread-pool и многопоточность лучше распределяют задачи по ядрам.
- Минимальные API и оптимизация исключений дали ещё +15% к скорости.
📊 Бенчмарки показывают:
- Java (Spring) — медленнее в 2.5 раза
- Go (Fiber) — в 1.3 раза
- Node.js (Fastify) — в 4 раза
- Python (FastAPI) — в 10 раз
- PHP (Laravel) — в 15 раз
- Ruby (Rails) — в 20 раз
💡 Итог: .NET 9 — быстрый старт, низкая задержка и топ-производительность. Отличный выбор для веба, микросервисов и облака.
#dotnet #performance #benchmark #backend
Microsoft прокачала .NET так, что он обгоняет почти все популярные фреймворки: Java, Go, Node.js, Python и даже PHP.
🚀 Что сделали:
- Мусорщик (GC) стал адаптивным → меньше пауз даже при высоких нагрузках.
- JIT-компилятор быстрее разогревает код и оптимизирует горячие участки.
- Векторизация через AVX10 и Arm SVE ускоряет циклы в несколько раз.
- Native AOT уменьшает размер бинарников и ускоряет запуск (контейнеры, IoT, edge).
- Сеть (сокеты, HTTP/3) стала работать быстрее с низкой задержкой.
- JSON обрабатывается через System.Text.Json максимально эффективно.
- Меньше аллокаций → меньше нагрузка на память и GC.
- Thread-pool и многопоточность лучше распределяют задачи по ядрам.
- Минимальные API и оптимизация исключений дали ещё +15% к скорости.
📊 Бенчмарки показывают:
- Java (Spring) — медленнее в 2.5 раза
- Go (Fiber) — в 1.3 раза
- Node.js (Fastify) — в 4 раза
- Python (FastAPI) — в 10 раз
- PHP (Laravel) — в 15 раз
- Ruby (Rails) — в 20 раз
💡 Итог: .NET 9 — быстрый старт, низкая задержка и топ-производительность. Отличный выбор для веба, микросервисов и облака.
#dotnet #performance #benchmark #backend
⚙️ 3 способа определить Middleware в ASP.NET Core
Middleware - это компоненты, которые добавляют дополнительную логику до или после обработки HTTP-запроса.
С их помощью можно реализовать аутентификацию, логирование, кеширование, обработку ошибок и другие сквозные функции приложения.
🔧 В ASP.NET Core уже встроено множество middleware (Static Files, Routing, Authentication и др.),
но вы можете создавать и свои собственные.
Вот три основных способа это сделать:
- Request Delegates - определяете логику прямо в
- Convention-based - создаёте класс с методом
- Factory-based - используете фабрику с внедрением зависимостей (DI)
🧠 Подробный разбор и примеры кода - в статье
#dotnet #aspnetcore #backend #middleware #csharp
Middleware - это компоненты, которые добавляют дополнительную логику до или после обработки HTTP-запроса.
С их помощью можно реализовать аутентификацию, логирование, кеширование, обработку ошибок и другие сквозные функции приложения.
🔧 В ASP.NET Core уже встроено множество middleware (Static Files, Routing, Authentication и др.),
но вы можете создавать и свои собственные.
Вот три основных способа это сделать:
- Request Delegates - определяете логику прямо в
app.Use(...) - Convention-based - создаёте класс с методом
Invoke или InvokeAsync - Factory-based - используете фабрику с внедрением зависимостей (DI)
🧠 Подробный разбор и примеры кода - в статье
#dotnet #aspnetcore #backend #middleware #csharp
🔥 EF Core 10 принес нормальные JOIN'ы в LINQ
Больше не нужно вспоминать, как извращаться с GroupJoin + DefaultIfEmpty, чтобы сделать обычный LEFT JOIN.
Теперь есть прямые методы:
✅ LeftJoin
✅ RightJoin
И они делают ровно то, что ты пишешь:
«Оставь все из левой таблицы и подтяни правые записи, если есть совпадения».
Плюсы
- Читаемость выше
- Код короче и очевиднее
- Транслируется в тот же SQL, что и раньше, но без боли
Примерно так LINQ наконец становится ближе к привычному SQL-пониманию разработчика: пишешь join — получаешь join, без магии и обходных путей.
Подробнее про LeftJoin и RightJoin в EF Core 10
#dotnet #efcore #csharp #linq #backend #devtools
Больше не нужно вспоминать, как извращаться с GroupJoin + DefaultIfEmpty, чтобы сделать обычный LEFT JOIN.
Теперь есть прямые методы:
✅ LeftJoin
✅ RightJoin
И они делают ровно то, что ты пишешь:
«Оставь все из левой таблицы и подтяни правые записи, если есть совпадения».
Плюсы
- Читаемость выше
- Код короче и очевиднее
- Транслируется в тот же SQL, что и раньше, но без боли
Примерно так LINQ наконец становится ближе к привычному SQL-пониманию разработчика: пишешь join — получаешь join, без магии и обходных путей.
Подробнее про LeftJoin и RightJoin в EF Core 10
#dotnet #efcore #csharp #linq #backend #devtools
🧠 EF Core и Repository: когда паттерн мешает, а не помогает
👶 Junior: использует EF Core прямо в контроллере
🧑 Middle: строит BaseRepository, IUnitOfWork, IOrderRepository, IOrderDataAccess...
🧓 Senior: снова использует EF Core — без репозиториев
Почему так?
Сначала Repository Pattern кажется удобным:
4 метода на CRUD — всё аккуратно.
Но как только домен растёт, появляются проблемы:
- Репозиторий на каждую сущность
- Общая логика между сущностями? Куда её девать?
- Репозитории раздуваются до 10+ методов
- Тестируемость становится фикцией: мокаем абстракцию от абстракции
А что насчёт "мы вдруг сменим базу"?
В 99% случаев — не смените.
EF Core и так абстрагирует SQL.
А при переходе на NoSQL придётся переписывать модели, запросы и подход целиком.
А что с "это улучшает разделение ответственности"?
На деле:
- В сервисах висит куча репозиториев
- Общая логика размыта
- Больше обвязки, больше боли, меньше пользы
✅ DbContext уже реализует Repository и Unit of Work.
И это официально указано в исходниках EF Core.
🔥 17 000+ разработчиков уже ушли от репозиториев к практичному использованию EF Core в:
- N-Layered архитектуре
- Clean Architecture
- Vertical Slice
- Specification Pattern
- Интеграционных тестах с in-memory
📖 Подробнее:
https://antondevtips.com/blog/why-you-dont-need-a-repository-in-ef-core
#dotnet #efcore #architecture #backend #repositorypattern
👶 Junior: использует EF Core прямо в контроллере
🧑 Middle: строит BaseRepository, IUnitOfWork, IOrderRepository, IOrderDataAccess...
🧓 Senior: снова использует EF Core — без репозиториев
Почему так?
Сначала Repository Pattern кажется удобным:
4 метода на CRUD — всё аккуратно.
Но как только домен растёт, появляются проблемы:
- Репозиторий на каждую сущность
- Общая логика между сущностями? Куда её девать?
- Репозитории раздуваются до 10+ методов
- Тестируемость становится фикцией: мокаем абстракцию от абстракции
А что насчёт "мы вдруг сменим базу"?
В 99% случаев — не смените.
EF Core и так абстрагирует SQL.
А при переходе на NoSQL придётся переписывать модели, запросы и подход целиком.
А что с "это улучшает разделение ответственности"?
На деле:
- В сервисах висит куча репозиториев
- Общая логика размыта
- Больше обвязки, больше боли, меньше пользы
✅ DbContext уже реализует Repository и Unit of Work.
И это официально указано в исходниках EF Core.
🔥 17 000+ разработчиков уже ушли от репозиториев к практичному использованию EF Core в:
- N-Layered архитектуре
- Clean Architecture
- Vertical Slice
- Specification Pattern
- Интеграционных тестах с in-memory
📖 Подробнее:
https://antondevtips.com/blog/why-you-dont-need-a-repository-in-ef-core
#dotnet #efcore #architecture #backend #repositorypattern