📘 Обновлённый обзор C#: история версий и ключевые новшества
Microsoft опубликовала подробную хронологию C# — от версии 1.0 до последней, показывая эволюцию языка за 20+ лет:
🕰️ Обзор ключевых этапов:
• C# 1.0–2.0 — классика: базовые ООП, exception-обработка, типы значений,
• C# 3.0 — революция LINQ,
• C# 4.0 —
• C# 5.0 —
• C# 6.0 — улучшения синтаксиса: string interpolation, expression-bodied members, null-условные выражения
• C# 7.x —
• C# 8.0 — nullable reference types,
• C# 9.0 —
• C# 10 — глобальные
• C# 11 — raw string literals, generic math, pattern matching improvements
• C# 12 и далее — ожидаются расширенные метапрограммирование, списочные выражения, улучшения в безопасность и производительности
🔧 Почему это важно:
• Язык постоянно развивается, становясь выразительнее, безопаснее и удобнее
• Новые версии дают мощные инструменты — для асинхронного программирования, функционального стиля и более чистого кода
• Понимание изменений помогает быстрее адаптироваться к трендам и выбирать актуальный инструментальный стек
💡 Если вы разрабатываете на C#, стоит ознакомиться с историей версий — и понять, какие фичи уже доступны, а что стоит ожидать в будущем.
👉 Подробнее
@csharp_ci
#dotnet #csharp #programming #developer #language #whatsnew #technology
Microsoft опубликовала подробную хронологию C# — от версии 1.0 до последней, показывая эволюцию языка за 20+ лет:
🕰️ Обзор ключевых этапов:
• C# 1.0–2.0 — классика: базовые ООП, exception-обработка, типы значений,
generics • C# 3.0 — революция LINQ,
lambda`-выражения, автоматические свойства, `var • C# 4.0 —
dynamic, улучшения COM и переговорчивость аннотации • C# 5.0 —
async/await — асинхронность для всех • C# 6.0 — улучшения синтаксиса: string interpolation, expression-bodied members, null-условные выражения
• C# 7.x —
tuples, pattern matching, ref locals, out variables • C# 8.0 — nullable reference types,
ranges/indices, асинхронные потоки • C# 9.0 —
record, init-only properties, top-level statements • C# 10 — глобальные
using, file-scoped namespace, улучшенные структуры • C# 11 — raw string literals, generic math, pattern matching improvements
• C# 12 и далее — ожидаются расширенные метапрограммирование, списочные выражения, улучшения в безопасность и производительности
🔧 Почему это важно:
• Язык постоянно развивается, становясь выразительнее, безопаснее и удобнее
• Новые версии дают мощные инструменты — для асинхронного программирования, функционального стиля и более чистого кода
• Понимание изменений помогает быстрее адаптироваться к трендам и выбирать актуальный инструментальный стек
💡 Если вы разрабатываете на C#, стоит ознакомиться с историей версий — и понять, какие фичи уже доступны, а что стоит ожидать в будущем.
👉 Подробнее
@csharp_ci
#dotnet #csharp #programming #developer #language #whatsnew #technology
Microsoft.Extensions.AI (Preview) — единый способ подключать ИИ в .NET
Библиотеки Microsoft.Extensions.AI призваны упростить жизнь .NET-разработчикам, которые начинают использовать генеративный ИИ в своих приложениях.
🧱 Вместо разрозненных SDK для каждого провайдера — единые "AI building blocks", которые можно подключать и переключать между OpenAI, Azure, Hugging Face и другими.
📦 Что даёт:
– Единый интерфейс для разных AI-провайдеров
– Простая интеграция в pipeline .NET-приложения
– Расширяемая архитектура: можно добавлять собственные провайдеры
– Поддержка RAG-сценариев, чат-интерфейсов, промптинга, трансформаций данных и т.д.
Полезно и для ASP.NET-приложений, и для десктопа, и для фона.
🧪 Пока в превью — но уже можно попробовать:
https://github.com/dotnet/ai-samples?tab=readme-ov-file#microsoftextensionsai-preview
#dotnet #ai #ml #microsoft
@csharp_ci
Библиотеки Microsoft.Extensions.AI призваны упростить жизнь .NET-разработчикам, которые начинают использовать генеративный ИИ в своих приложениях.
🧱 Вместо разрозненных SDK для каждого провайдера — единые "AI building blocks", которые можно подключать и переключать между OpenAI, Azure, Hugging Face и другими.
📦 Что даёт:
– Единый интерфейс для разных AI-провайдеров
– Простая интеграция в pipeline .NET-приложения
– Расширяемая архитектура: можно добавлять собственные провайдеры
– Поддержка RAG-сценариев, чат-интерфейсов, промптинга, трансформаций данных и т.д.
Полезно и для ASP.NET-приложений, и для десктопа, и для фона.
🧪 Пока в превью — но уже можно попробовать:
https://github.com/dotnet/ai-samples?tab=readme-ov-file#microsoftextensionsai-preview
#dotnet #ai #ml #microsoft
@csharp_ci
🔥 Одна из дучших фишек в ASP.NET Core 10 — Server-Sent Events (SSE)
Теперь можно реализовать real-time обновления без SignalR и WebSockets. SSE — это лёгкий способ стримить данные с сервера на клиент *в одну сторону*, идеально для простых задач.
📡 Зачем это нужно?
В .NET-приложениях часто нужно передавать обновления с backend на frontend. Есть несколько способов:
• Polling — клиент всё время спрашивает: «что нового?» (нагружает сервер)
• SignalR — bidirectional WebSockets, но избыточно для простых стримов
• SSE — простой и нативный способ отправлять обновления *односторонне*
Теперь SSE доступен прямо в .NET 10 (preview) и легко интегрируется с Minimal APIs.
🧠 Что сегодня показали:
— Как работает SSE и чем отличается от SignalR
— Как реализовать SSE endpoint с Minimal API
— Как тестировать SSE-поток из IDE (HTTP request file)
— Как собрать frontend для отображения стриминга
— И как создать *живой рынок акций* на SSE — от бэкенда до клиента
👨💻 Отличная альтернатива, если нужно real-time, но без всей сложности WebSockets.
#dotnet #aspnetcore #SSE #ServerSentEvents #SignalR #realtime #webdev
Теперь можно реализовать real-time обновления без SignalR и WebSockets. SSE — это лёгкий способ стримить данные с сервера на клиент *в одну сторону*, идеально для простых задач.
📡 Зачем это нужно?
В .NET-приложениях часто нужно передавать обновления с backend на frontend. Есть несколько способов:
• Polling — клиент всё время спрашивает: «что нового?» (нагружает сервер)
• SignalR — bidirectional WebSockets, но избыточно для простых стримов
• SSE — простой и нативный способ отправлять обновления *односторонне*
Теперь SSE доступен прямо в .NET 10 (preview) и легко интегрируется с Minimal APIs.
🧠 Что сегодня показали:
— Как работает SSE и чем отличается от SignalR
— Как реализовать SSE endpoint с Minimal API
— Как тестировать SSE-поток из IDE (HTTP request file)
— Как собрать frontend для отображения стриминга
— И как создать *живой рынок акций* на SSE — от бэкенда до клиента
👨💻 Отличная альтернатива, если нужно real-time, но без всей сложности WebSockets.
#dotnet #aspnetcore #SSE #ServerSentEvents #SignalR #realtime #webdev
⚡ .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
❌ Exceptions ≠ Errors
Многие разработчики путают эти понятия и проектируют приложения неправильно. Давайте разберём:
Что такое исключение (exception)?
Это ситуация, из которой приложение не может восстановиться.
Пример: критическая ошибка базы данных, повреждённый файл конфигурации.
Что такое ошибка (error)?
Это ожидаемое состояние сбоя или невыполненное предусловие.
Пример: пользователь ввёл неверный пароль, файл не найден, запрос не прошёл валидацию.
👉 Использовать исключения вместо ошибок = анти-паттерн. Так появляется flow control через исключения, который делает код непредсказуемым и запутанным.
Как правильно:
- Ошибки представляем явно в коде (например, через
- Исключения оставляем для действительно неожиданных и фатальных ситуаций.
Бонус: Явные ошибки делают намерения кода прозрачными и облегчают поддержку.
📖 Подробнее: https://milanjovanovic.tech/blog/functional-error-handling-in-dotnet-with-the-result-pattern
#dotnet #cleanCode #architecture
Многие разработчики путают эти понятия и проектируют приложения неправильно. Давайте разберём:
Что такое исключение (exception)?
Это ситуация, из которой приложение не может восстановиться.
Пример: критическая ошибка базы данных, повреждённый файл конфигурации.
Что такое ошибка (error)?
Это ожидаемое состояние сбоя или невыполненное предусловие.
Пример: пользователь ввёл неверный пароль, файл не найден, запрос не прошёл валидацию.
👉 Использовать исключения вместо ошибок = анти-паттерн. Так появляется flow control через исключения, который делает код непредсказуемым и запутанным.
Как правильно:
- Ошибки представляем явно в коде (например, через
Result, Option, Either паттерны). - Исключения оставляем для действительно неожиданных и фатальных ситуаций.
Бонус: Явные ошибки делают намерения кода прозрачными и облегчают поддержку.
📖 Подробнее: https://milanjovanovic.tech/blog/functional-error-handling-in-dotnet-with-the-result-pattern
#dotnet #cleanCode #architecture
⚙️ 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