В заметке описан способ динамического добавления на страницу компонентов по JSON-описанию с помощью DynamicComponent из ASP.NET Core 6.0 (в настоящее время в статусе Preview).
Динамическое создание компонентов пригодится например при реализации конструктора форм:
• Форма описывается JSON-ом;
• Элементы (или контролы) формы не ограничены предустановленным набором. Контролы можно добавлять, в том числе подгружать из других dll-библиотек.
Имеем ASP.NET web приложение. Проблема в том, что приложение может выполнять как "обычные" запросы так и тяжелые запросы построения отчетов. Все запросы по умолчанию выполняются в одном Application Pool. И в случае обработки запросов на построение отчетов страдает производительность.
Задача: вынести построение отчетов в отдельный Application Pool на отдельный домен. Допустим основной сайт расположен на домене main.domain.xyz. Нам требуется все GET запросы содержащие в URL /Reports/Run обрабатывать на другом домене reports.domain.xyz.
Распределенные приложения сложны и влекут за собой свой собственный караван трудностей с отладкой и исправлением проблем в продакшене. Хотя микросервисная архитектура и дает возможность справляться силами меньшей команды, которая работает автономно и фокусируется на разных областях бизнеса, из-за своего распределенного характера она подкидывает нам новые проблемы. Например, в случае возникновения проблемы во время бизнес-транзакции, запрос необходимо отслеживать от начала и до конца, что может охватывать несколько служб и инфраструктур. Некоторые из трудностей таковы:
Мы начали поставлять IdentityServer4 в .NET 3.0 как часть нашего шаблона для поддержки выдачи JWT токенов для SPA и Blazor приложений. Через некоторое время после того, как мы выпустили продукт, команда IdentityServer сделала объявление об изменении лицензии для будущих версий IdentityServer на взаимную публичную лицензию (RPL) — лицензию, в которой код по-прежнему является открытым, но если он используется в коммерческих целях, необходимо покупать платную лицензию. Такой подход распространен в мире опенсорсного кода, где получать стабильный доход может быть достаточно трудно, поскольку ваш проект становится вашей работой на полную ставку.
Двумя вескими причинами, по которым мы решили поставлять IdentityServer, было четко выраженное желание сообщества не конкурировать с уже существующим опенсорсным проектом и глубокое понимание IdentityServer области идентификации. Команда .NET не является экспертом по OAuth и OIDC, поскольку мы сосредоточены на предоставлении строительных блоков для вашего приложения и отправной точке, с которой вы можете добиться успеха. Создание и поддержка сервера аутентификации - это постоянная задача, и у Microsoft уже есть команда и продукт в этой области, Azure Active Directory, который позволяет бесплатно использовать 500 000 объектов. Команда ASP.NET считает, что управляемое облачное решение остается лучшим практическим решением для разработчиков — безопасность управляется, учетные данные не хранятся локально, что сопряжено с риском, а новые фичи, такие как аутентификация без пароля, бесшовно вплетаются в ваш рабочий процесс аутентификации. Однако мы также понимаем, что облачное решение может быть невозможно для некоторых клиентов из-за проблем с нормативными требованиями или суверенитетом данных.
Мы продолжаем серию статей о создании HTTP API с помощью .NET 5. В предыдущей статье мы рассмотрели создание обнаруживаемых HTTP API с помощью ASP.NET Core 5 Web API. В этой статье мы рассмотрим пакеты и инструменты для работы с HTTP API с открытым исходным кодом. Ну что ж, приступим!
«Ваши .NET контроллеры должны быть тонкими»
Ох уж эта вечно повторяемая банальность, обросшая тоннами недосказанности.
Почему они должны быть тонкими? Какой в этом плюс? Как сделать их тонкими, если они сейчас не такие? Как сохранить их тонкими?
Хотите добиться нестандартного поведения от aspnet core? Мне вот понадобилось добавить прозрачную поддержку Json Rpc. Расскажу о том, как я искал решения для всех хотелок, чтобы вышло красиво и удобно. Может быть, вам пригодятся знания о разных точках расширения фреймворка. Или о тонкостях поддержки Json Rpc, даже на другом стеке/языке.
В результате получилась библиотека, которая позволяет работать с Json Rpc, вообще не задумываясь, что он спрятан под капотом. При этом пользователю не нужно уметь ничего нового, только привычный aspnet mvc.
Новая версия .NET, 6 Preview 1, уже доступна и готова к вашей оценке. Это первая предварительная версия .NET 6, следующего крупного обновления платформы .NET. Ожидается, что .NET 6 поступит в полноценный доступ в ноябре этого года и будет выпуском с долгосрочной поддержкой (LTS).
Если вы работаете с Windows и используете Visual Studio, мы рекомендуем установить последнюю предварительную версию Visual Studio 2019 16.9. Если вы используете macOS, мы рекомендуем установить последнюю предварительную версию Visual Studio 2019 для Mac 8.9.
Сегодня в этой статье мы обсудим концепцию обработки исключений в приложениях ASP.NET Core. Обработка исключений (exception handling) — одна из наиболее важных импортируемых функций или частей любого типа приложений, которой всегда следует уделять внимание и правильно реализовывать. Исключения — это в основном средства ориентированные на обработку рантайм ошибок, которые возникают во время выполнения приложения. Если этот тип ошибок не обрабатывать должным образом, то приложение будет остановлено в результате их появления.
В ASP.NET Core концепция обработки исключений подверглась некоторым изменениям, и теперь она, если можно так сказать, находится в гораздо лучшей форме для внедрения обработки исключений. Для любых API-проектов реализация обработки исключений для каждого действия будет отнимать довольно много времени и дополнительных усилий. Но мы можем реализовать глобальный обработчик исключений (Global Exception handler), который будет перехватывать все типы необработанных исключений. Преимущество реализации глобального обработчика исключений состоит в том, что нам нужно определить его всего лишь в одном месте. Через этот обработчик будет обрабатываться любое исключение, возникающее в нашем приложении, даже если мы объявляем новые методы или контроллеры. Итак, в этой статье мы обсудим, как реализовать глобальную обработку исключений в ASP.NET Core Web API.
Program.cs — это место, с которого начинается приложение. Файл Program.cs в ASP.NET Core работает так же, как файл Program.cs в традиционном консольном приложении .NET Framework. Файл Program.cs является точкой входа в приложение и отвечает за регистрацию и заполнение Startup.cs, IISIntegration и создания хоста с помощью инстанса IWebHostBuilder, метода Main.
Global.asax больше не входит в состав приложения ASP.NET Core. В ASP.NET Core заменой файла Global.asax является файл Startup.cs.
Файл Startup.cs - это также точка входа, и он будет вызываться после выполнения файла Program.cs на уровне приложения. Он обрабатывает конвейер запросов. Класс Startup запускается в момент запуска приложения.
Понимание жизненного цикла внедряемых зависимостей в приложениях ASP.Net Core очень важно. Как мы знаем, внедрение зависимостей (DI - Dependency Injection) - это метод достижения слабой связанности между объектами и их коллабораторами, или зависимостями. Чаще всего классы объявляют свои зависимости через конструктор, в рамках реализации принципа явных зависимостей (Explicit Dependencies Principle). Этот подход известен как «constructor injection».
Чтобы реализовать внедрение зависимостей, нам нужно настроить DI-контейнер с классами, которые участвуют во внедрении зависимостей. DI-контейнер должен решать, возвращать ли новый инстанс сервиса или предоставить уже существующий. Мы выполняем это действие с помощью метода ConfigureServices в классе startup.
Возможно, многим знакома библиотека ELMAH (Error Logging Modules and Handlers), которая позволяет организовать простое журналирование ошибок для любого сайта, созданного с помощью .NET Framework.
Этот простой и проверенный временем инструмент выручал меня во многим проектах.
Несколько лет назад, создавая свой новый проект под .NET Core я с досадой обнаружил, что ELMAH не работает под .NET Core.
Но это же opensource проект! Несколько выходных в работе над форком, и вот готова первая версия ELMAH работающая под .NET Core.
С тех пор много воды утекло, и признаюсь, я несколько забросил свой pet-проект. Однако, сейчас выдалась небольшая передышка между проектами, мне удалось внести существенные улучшения и хочу познакомить уважаемых «хабравчан» с новой версией ElmahCore.
Итак, Cake. Многие слышали, многие хотели попробовать, но откладывали. Конечно, если ты все время работал на TeamCity или на Jenkins и продолжаешь, то зачем переизобретать то, что уже отлично работает? Люби свою жизнь и радуйся. Но вот, допустим, в твоей любимой жизни появился новый проект, новый дедлайн, минимум сторипойнтов до релиза, а опыта с новым сборщиком нет? Мне в этом случае и пригодился Cake.
Я сразу оговорюсь, что эта статья не подтолкнет сразу на использование Cake, как меня, и многих моих коллег не подтолкнули статьи, которые выходили ранее. По большей части потому что на него нет смысла переходить в проекте, который не приносит боль и который работает стабильно. Собираете в своем любимом Jenkins и все идет нормально. Но пусть после этой статьи в голове отложится, что Cake существует. Он в очередной раз никуда не делся, он умеет уже многое и работать с ним все проще. Гораздо проще, чем было раньше.
На что похож Cake? Наверное, любой разработчик, не погрязший в мире .Net, найдет свою аналогию: gradle, gulp, golang make. Make-системы не откровение в 2020 году. Это всегда было удобно, а значит — нужно и правильно. Мир .Net долгое время был обделен такими средствами. Фактически был и есть до сих пор MSBuild, но у него есть очень-очень много недостатков. Основной - кто вообще умеет им пользоваться из рядовых разработчиков? И какова целесообразность его освоения? Какие-то базовые и нужные всем вещи явно проще делать на билд-сервере. Наверное, кому-то он и удобен, но я уверен, что значимая часть коммьюнити предпочтет MSBuild'у освоить новый билд-сервер. Один раз написать конфиг и забыть как страшный сон.
А что если бы существовала make-система с DSL на C#, автокомплитом и прочими фишками типизированного языка? Да, я про Cake. В частности сейчас пойдет разговор про библиотеку Cake.Frosting, являющуюся одним из раннеров make-системы.
Подробней про доступные раннеры можно прочитать тут: Cake Runners
С Frosting все привычно — самодокументирующийся Api с которым почти сразу находишь общий язык. Методы расширения, загружаемые из Nuget — на любой случай жизни, структура проекта, похожая на смесь тестов или бенчмарков и хоста Asp. Все решения угадываются сразу, все как дома.
Введение
Всем привет, в данной статье будет рассказано, как с использованием технологии C# ASP.NET Core написать простое Rest Api. Сделать Unit-тесты на слои приложений. Отправлять Json ответы. Также покажу, как выложить данное приложение в Docker.
В данной статье не будет описано, как делать клиентскую часть приложения. Здесь я покажу только серверную.
При проектировании и разработке широкого спектра API с использованием ASP.NET Core 2.1 Web API важно понимать, что это только первый этап в создании продуктивного и стабильного решения. Наличие стабильной среды для вашего решения также очень важно. Ключ к отличному решению заключается не только в правильном построении API, но и в его тщательном тестировании, чтобы исключить возможность негативного опыта у пользователей во время использования вашего API.
Эта статья является продолжением моей предыдущей статьи для InfoQ под названием «Продвинутая архитектура веб-API ASP.NET Core». Не беспокойтесь, вам не нужно вникать в предыдущую статью, чтобы разобраться с тестированием в этой, но она может помочь вам лучше понять, как я спроектировал обсуждаемое здесь решение. На протяжении последних нескольких лет я много времени размышлял о тестировании, создавая API для клиентов. Знание архитектуры веб-API ASP.NET Core 2.1 может помочь и вам расширить ваше понимание.
Солюшн и весь код из примеров в этой статье можно найти в моем GitHub репозитории.
