.NET спустя 10 лет: актуальность технологий и навыков

Всем привет. Меня зовут Владислав Фурдак, являюсь .NET техлидом, c платформой .NET работаю около 10 лет. Ранее писал на DOU о карьерных темах, а также технические статьи. Эта статья покажет, как изменилась разработка на .NET за последние 10 лет, какие навыки стали более актуальными, а какие уже устаревшие.

Что теряет популярность

C#

• Вам уже наверняка никогда не понадобится писать свои типы делегатов, так как есть обобщенные Action, Func и Predicate.
• Среди асинхронных моделей разработки (EAP, APM, TAP) — EAP & APM считаются устаревшими, так же некоторые из элементов TAP являются устаревшими тоже.

  Например, в TAP есть рекомендации по именованию асинхронных методов постфиксом Async. Но де-факто весь код, что пишется уже по умолчанию, должен быть асинхронным. Следовательно, Async используется только в случае, если в разрабатываемом нами модуле есть альтернативная синхронная версия метода.

  С появлением async/await в C#5 подходы к TAP изменились. Теперь обычный асинхронный поток выполнения есть смысл писать только через await, без ContinueWith у Task. Более подробно я это описывал в своей статье об асинхронном программировании.

• В применении паттернов проектирования уже нет смысла писать вариации Singleton’a, например потокобезопасные, потому что управление жизненным циклом объектов осуществляется через IoC контейнеры, Singleton scope.
• Устаревшим считается класс TransactionScope.Ambient — транзакции считаются дурным тоном по следующим причинам:
  • Нужно быть уверенным, что ваш провайдер для O\RM его поддерживает в полной мере.
  • Есть риск запустить распределенную транзакцию, что требует дополнительных сервисов и является довольно медленным и устаревшим подходом.
  • Возможны конфликты с асинхронным кодом, необходимо выставлять дополнительные опции.
• Знания многопоточности уже не так сильно решают, Microsoft сделало все для того, чтобы снизить необходимость писать многопоточный код и управлять примитивами синхронизации в бизнес-приложениях.

Я уже не могу представить случая, когда вам нужно будет создавать вручную классы Thread’ов. В случае необходимости выполнения в отдельном потоке единицы работы — можно использовать Task с опциями LongRunning.

Возможно, единственным случаем может быть написание своего TaskScheduler’a (планировщика задач, по сути стратегии размещения тасок в потоках) при разработке нового фреймворка, где это необходимо, например в Microsoft Orleans, фреймворке для создания высоконагруженного серверного кода, написан свой однопоточный Task Scheduler.

Там, где можно избежать многопоточности — избегайте ее. Например, вместо синхронизации доступа к коллекциями — можно использовать коллекции из пространства имен Concurrent.

Для запуска параллельных задач — используйте средства Task Parallel Library либо же Task API.

В случае все же необходимости использовать конструкции синхронизации, используйте CLR-версии вместо конструкций уровня ядра ОС, например SemaphoreSlim вместо Semaphore.

• В Unit-тестировании отпала необходимость в использовании моков источников данных вокруг DbContext. При использовании Entity Framework, мы можем использовать In-memory DB provider, заранее наполняя коллекции тестовыми данными.
• В .NET Core/.NET 5 консольных приложениях конфигурирование сведено в единое место с помощью Generic Host, который теперь отделен от веб-сервера. Управлять внедрением зависимостей, логированием, конфигурациями, переменными окружения, аргументами командной строки стало удобней.
• Новые фичи языка делают его не только более лаконичным, но и более производительным:

Кажется, что C# целиком вытеснил VB.NET. Второй по популярности CLR-язык это F# - в узких кругах считается самым элегантным языком. Является действительно мощным средством функционального программирования.

CLR & Compiler

• Вместо MSBuild теперь используют утилиту dotnet, как более простой CLI для .NET Core приложений, однако под капотом он продолжает использовать MSBuild. Компилятор не требует установленной VisualStudio, как это было с первыми версиями Roslyn’a, который поставлялся в виде Nuget-пакетов.
• .NET Core принес нам новый способ конфигурирования проекта через Project.SDKs
• Довольно значимой фичей в .NET 5 стал App Trimming (Tree shaking). Удаление неиспользуемого кода из сборок стало довольно актуально для Blazor WebAssembly-приложений, а также для более быстрого развертывания серверного кода.

Напомню, что следующим релизом .NET после ASP.NET Core 3.x является .NET 5.

Полный список новых фич .NET 5 можно глянуть тут.

ASP.NET Core

Стандартный веб-фреймворк от Microsoft сделал огромный шаг вперед, по сравнению с тем, что было до этого (classic asp.net).

Во-первых: были внедрены концепции, давно прижившиеся в других технологических стеках: механизм middleware, более гибкая и понятная конфигурация через код, наличие конфигов в JSON, собственный веб-сервер без привязки к IIS/Windows и так далее.

Во-вторых: стало возможным хостится под Linux, что сразу же снизило затраты и повысило производительность.

В-третьих: фреймворк стал с открытым исходным кодом, что повысило доверие.

Сам ASP.NET Core из версии в версию становится еще более производительным.

В ASP.NET изначально был доступен JavaScriptSerializer.

Со временем популярным стал Newtonsoft Json, который стал рекомендуемым от Microsoft.

Начиная с asp.net core 3 сериализатором по умолчанию стал System.Text.Json , но для asp.net core 2 придется устанавливать вручную.

System.Text.Json имел довольно ограниченный набор фич по сравнению с Newtonsoft, но работает быстрей. Однако последние релизы System.Text.Json приближают его к сериализатору от Newtonsoft.

Работа с источниками данных

Entity Framework Core:

• Lazy Loading уже не используется.
• Model & DB First с использованием EDMX (конструктор маппингов концептуальной и реальной модели).
• In Memory DB Provider для тестов и быстрого начала разработки.
• Fluent API как более удобный способ описания схемы данных.

Кроме MS SQL Server для микросервисов чаще стали использовать Postgree либо вариации MySQL ввиду их цены.

Общая парадигма разработки смещается от Data-centric приложений к распределенным системам. Конечно, множество приложений строится с использованием сложных схем данных и объектов БД, но в распределенных системах, построенных с микросервисным подходом производительность достигается за счет асинхронности и масштабирования, нежели тюнинга одной большой базы.

Множество разработчиков уже с 4-5 годами опыта никогда не писали чистые SQL-объекты и сложные запросы в базе данных, работая только с O/RM средствами.

Операционная система и веб

С всеобщей контейнеризацией и возможностью запуска .NET Core приложений под Linux — production среда под Windows уже не так актуальна.

IIS уже используется гораздо реже, чаще работает связка NGINX + встроенный Kestrel, либо же любой другой обратный прокси, запуская приложения в контейнерах.

IIS может пригодиться в таких случаях:

1. Множество приложений на одном порте.
2. Продвинутая фильтрация запросов.
3. Windows Authentication.
4. Mime Type Mapping.
5. Логирование HTTP.
6. IIS как API Gateway на windows машине.

Разберем это детально:

1. Множество приложений на одном порте — в случае контейнеризации это уже не нужно, а даже вредно.
2. Продвинутая фильтрация запросов — может быть настроена на уровне API Gateway либо Service mesh.
3. Windows Authentication — может быть настроено с помощью отдельного Nuget-пакета.
4. Mime Type Mapping — может быть настроено на уровне приложения либо API Gateway
5. Логирование HTTP — может быть настроено на уровне приложения, API Gateway либо Service mesh.

Более полное сравнение IIS и Kestrel можно посмотреть тут.

В целом Kestrel нельзя рассматривать как веб-сервер для production-окружения, всегда нужен reverse-proxy.

Так же менее популярна становится аутентификация с использованием Cookies, гораздо гибче выдавать Bearer/JWT токен, универсальный для любых устройств.

Для того, чтобы отделить логику аутентификации от логику всего приложения мы можем использовать постороннего поставщика аутентификации вроде Azure Active Directory или Okta.

Но asp.net identity/identity server тоже остается валидным подходом, но гораздо проще использовать аутентификацию как сервис.

Что набирает популярность

Архитектура конкретного сервиса

Стали популярными подходы, кроме трехслойной архитектуры:

• Clean Architecture
• Onion Architecture
• Hexagonal Architecture

Разница и преимущества этих подходов к дизайну модуля достойны отдельной статьи.

Архитектура распределенных систем

Все чаще это микс между микросервисами и serverless. Cloud начинает быть де-факто стандартом для инфраструктуры приложений, в виду удобства использования и перекрытия рисков для бизнеса.

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

Независимо от конкретного облака из наиболее часто используемых облачных объектов:

• Виртуальные машины.
• Очереди.
• Managed базы данных.
• Функции/лямбды.
• Хранилища конфигурации/секретов.
• Пайплайны для деплоймента.
• Управляемые облачные оркестраторы (например Kubernetes).
• BLOB-хранилища.
• CDN.
• Средства диагностики и логирования.

Новые подходы в языке C#

• Последние релизы C# в большей степени приобретает фичи, свойственны функциональным языкам программирования, например:
  • pattern matching в switch/case;
  • еще больше Pattern matching’a в логических выражениях;
  • immutable records;
  • лямбда-функции;
  • синтаксический сахар различных инициализаций.

Бизнес-логика все чаще пишется в функциональном стиле с использованием LINQ, поэтому я считаю хорошее знание LINQ это must have для C# разработчиков.

Из объектно-ориентированных фич за последнее время из значимого реализовали:

• Covariant returns.
• private protected модификатор доступа.
• Init only setters.

Для создания высокопроизводительного кода теперь можно использовать Spans.

С выходом .NET 5 набирает популярность Source Generation. А вот и список библиотек, реализующих эту возможность. Ранее похожие механизмы имплементировали с помощью T4 шаблонов.

Инфраструктура

Эпоха Teamcity и Jenkins заканчивается, гораздо более удобный подход это pipelines, например Azure DevOps pipelines либо Gitlab pipelines.

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

Тотальный переезд в облака создал довольно большой спрос на системных инженеров в практике DevOps, кто-то же должен это все поддерживать, автоматизировать, настраивать.

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

Довольно популярно стало использовать обертку над конкретным движком очереди MassTransit , чтобы сделать систему независимой и cloud-agnostic.

Протоколы общения клиент-сервер

Хоть HTTP не теряет популярности, но у нас сейчас много альтернатив, поддерживаемых ASP.NET Core:

• gRPC (proto)
• WebSockets (SignalR)
• GraphQL, требует 3rd-party пакетов.

Так же вышла поддержка TLS 1.3 / OpenSSL 1.1.1 в ASP.NET Core 3, HTTP/2 начиная с ASP.NET Core 2.2.

В мире высоконагруженных систем

Последние пару лет набирает популярность фреймворк Microsoft Orleans. Он служит для построения распределенных, устойчивых реал-тайм систем, требующих большой пропускной способности и мгновенного отзыва, идеально подходит например для:

• систем биржевой торговли в реальном времени;
• гемблинг-проектов: спортивные ставки, казино;
• бэкенда для любых игр в реальном времени;
• банковских кошельков.

Сам по себе фреймворк это имплементация модели акторов (Actor Model), от аналога Akka.NET отличается более богатым функционалом но меньшей популярностью и документацией. Небольшое вводное видео можно найти тут.

Клиентские фреймворки

Mobile: Xamarin. Microsoft стала владельцем Xamarin с 2016 года. Судя по трендам гугл популярность Xamarin в мире кросс-платформенных фреймворков для мобильной разработки остается стабильной и периодически снижается, в отличии от уверенного роста ReactNative.

Desktop/Mobile/Devices: UWP. UWP (Universal Windows Platform) можно считать более гибким и адаптивным приемником WPF. Был выпущен вместе с Windows 10, может быть запущен на любых устройствах с операционными системами от Microsoft: от ПК до SmartTV. Альтернативой также являются приложения на Electorn.

Web: Blazor. С одной стороны Революционный фреймворк, с другой еще одна реализация RIA (Rich internet application) в браузере.

Было уже множество попыток реализовать движки для Rich приложений в браузере: ActiveX ,JScript ,XAML, Silverlight, Java Applets, JavaFX, XUL, Flash/Flex, Dart.

Почти ни один не получил высокой популярности и не стал заменой JavaScript. Этому есть такие причины:

• Проприетарность разработки (является чьей-то собственностью, а не стандартом), следовательно не может быть поддержана конкурентами.
• Не может поддерживаться всеми браузерами даже технически.
• Имеет дыры в безопасности.
• Не имеет связи с комьюнити.

Первый, кто поборол это все стал стандарт HTML5, давший нам Canvas и WebGL с возможность быстрого рисования в браузере.

Следующим прорывом стал WebAssembly. Опять таки, его поддерживали все ключевые игроки на рынке браузеров, потому как это был стандарт, а не чья-то разработка.

С развитием WebAssmebly стало возможным запускать высокопроизводительный код прямо в браузере.

Все, что оставалось — это портировать CLR под запуск в браузере.

Сам же Blazor — прикладной фреймворк, построенный для работы на CLR в браузере. Довольно активно развивается, так же, хоть и с осторожностью, но начинает использоваться компаниями.

В отличии от технологий, основанных на плагинах и закрытых разработках — Blazor основывается на стандарте, который лежит в основе всех современных браузеров.

Имеет разные модели исполнения:

• Выполнение на сервере, с обновлениями клиента по веб-сокетам.
• Выполнение на клиенте, с загрузкой CLR и клиентского кода.

Кстати, можете глянуть впечатляющий список open-source разработок с использованием Blazor, также книги, статьи, курсы посвященные технологии.

MAUI (.NET Multi-platform App UI)
Также новинкой стал MAUI , который может быть использован в Xamarin.Forms для кроссплатформенного использования и так же будет портирован для Blazor. Характерным отличием есть присутствие UI паттерна под названием MVU (Model-View-Update).

Messengers: Bot Framework. Bot Framework — заточен на создание приложения, которое общается с человеком посредством мессенджеров. Имеет встроенный набор когнитивных сервисов, позволяющий внедрять сложные интерактивные сценарии в общение с человеком.

Машинное обучение

ML.NET — набор средств для аналитики, вычислений, машинного обучения. Может являться оберткой вокруг TensorFlow, ONNX, Infer.NET, и других.

Инструментарий и среда разработки

Несмотря на постоянно улучшающуюся Visual Studio, многие разработчики (в том числе и я) предпочли Rider. Альтернативой может быть Resharper в VisualStudio, однако из-за ограничений по памяти и имплементации в виде плагина — он может работать не так быстро.В Rider мне нравится UX и производительность. Написание кода через Rider, в случае если вы хорошо освоили все его возможности ускоряется в несколько раз.

Так же отмечу и другие продукты от JetBrains:

• DotPeek — тот же рефлектор, декомпилятор.
• DotMemory — исследование потребления памяти, профайлинг управляемой кучи.
• DotTrace — профайлер производительности.
• DotCover — code coverage, менеджер юнит-тестов.

В заключение

Добавляйтесь в мое комьюнити в Telegram для людей изучающих .NET. На момент написания статьи там уже около 800 человек.

Также рекомендую глянуть список украинских сообществ по .NET тематике.

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті