Небольшой обзор стандартных средств запуска бэкграунд-задач в аспнет приложениях — что есть, чем отличается, как пользоваться. Встроенный механизм запуска таких задач строится вокруг интерфейса IHostedService и метода-расширения для IServiceCollection — AddHostedService. Но есть несколько способов реализовать фоновые задачи через этот механизм (и ещё несколько неочевидных моментов поведения этого механизма).
Можно считать это продолжением публикации Кастомный JsonConverter: уменьшаем связность и экономим ресурсы. Там при рассмотрении списков верхнего уровня упор был сделан на десериализацию из JSON. Но чтобы что-то десериализовать, нужно сначала это сериализовать. Посмотрим, чем нам может помочь возможность сериализации IAsyncEnumerable<T> объекта.
Рассматриваем некоторые возможности, которые нам предоставляет кастомный JsonConverter.
Привет! Я Антон Антонов, Full Stack Developer из Plarium Krasnodar. Расскажу, как обрабатываю необработанные исключения в ASP.NET Core Web API, и дам примеры обработчиков ошибок, которые отвечают наиболее распространенным требованиям.
Соглашаясь с мнением, что stateful-сервер ограничен в масштабируемости, всё же считаю, что инструмент должен соответствовать задаче. Для высоконагруженной системы с миллионами запросов в секунду важна распределённость, но за неё мы платим необязательностью предоставления актуальных данных в конкретный момент. Ни того ни другого нельзя сказать о системе, в которой при самых оптимистичных предположениях будет работать сотня операторов.
Так что предположим, что запрос на полноценные сессии всё же имеется. И эти сессии надо как-то утилизировать после окончания их срока жизни. Навскидку можно предложить следующие решения.
Запуск параллельной задачи при очередном запросе с клиента.
Запуск специального потока.
Использование таймера.
Всё же осмелюсь предложить ещё одну идею.
Обновление: благодарю @Politura - комментарий о MemoryCache оказался очень полезным! Проверил и решил так и сделать.
Одно из двух, — прошелестел он, — или пациент жив, или он умер. Если он жив — он останется жив или он не останется жив. Если он мёртв — его можно оживить или нельзя оживить.
А.Н. Толстой. "Золотой ключик, или Приключения Буратино"
Пользователю лень фильтровать запрашиваемые данные, а их бывает довольно много. Заставлять пользователя что-то фильтровать - негуманно и попахивает произволом. В таком случае пользователь сидит грустит, ругает разработчиков, давит на техподдержку. Если сделать "в лоб", сервер по запросу клиента будет собирать для отправки коллекцию объектов, загружая их из базы или ещё как-то. Потом всю эту махину он пошлёт в ответном HTTP-пакете, предварительно серилизовав в JSON, там это всё будет в один присест десериализовано в клиентские объекты, которые, наконец-то предстанут пред взором потерявшего надежду пользователя.
RabbitMQ – это брокер сообщений, служба, отвечающая за обмен сообщениями между разными программными сервисами.
RabbitMQ держит сообщения в очереди (Queue), которая является именованным буфером, хранящим адресованные ему сообщения.
Программа, посылающая сообщения в очередь RabbitMQ, называется поставщиком (Producer).
Программа, принимающая сообщения, называется подписчиком (Consumer). Такие программы подписываются на события поступления сообщения в очередь, и всегда находятся в ожидании новых сообщений.
Множество поставщиков могут отправлять сообщения в очередь, и множество подписчиков могут считывать сообщения из очереди.
Поддерживая существующие уже какое-то время Web API проекты, мы нередко сталкиваемся с проблемой устаревания логики методов контроллеров и необходимостью ее изменения в соответствии с новыми требованиями. Но, как правило, на момент возникновения такой необходимости, уже существует определенное число сервисов, использующих текущую реализацию наших API, и не нуждающихся в ее модернизации. Более того, такие сервисы могут легко «сломаться» при изменении используемых ими API.
Для решения такого рода проблем в ASP.Net Core существует механизм версионирования API – когда контроллеры и их методы могут существовать одновременно в разных версиях. В таком случае, те сервисы, которым достаточно существующего состояния используемых ими API, могут продолжать использовать определенные версии этих API, а для сервисов, которые требуют модернизации логики контроллеров, мы можем создавать новые параллельные версии, и все эти версии могут работать в нашем проекте одновременно.
При работе с данными (и не только) нам часто приходится сталкиваться с необходимостью копирования (маппинга) значений свойств одного объекта в новый объект другого типа.
Например предположим, что запрос к базе данных возвращает нам запись в виде объекта, представленного классом Person:
В этой статье мы создадим веб-приложение, используя Blazor, .Net 6.0 и Entity Framework Core для выполнения CRUD операций на базе Asp.Net Core.
В этом руководстве мы будем использовать Visual Studio 2022 и SQL Server 2014.
Эксперименты с созданием редактора диаграмм на Blazor Webassembly (Blazor WebAssembly: Drag and Drop в SVG, Blazor WebAssembly: соединительные линии в SVG) показали что технология не годится для интенсивных манипуляций с DOM.
То что будут проседания было известно заранее: WebAssembly не имеет доступа к DOM, любые изменения только через вызовы JavaScript. Задержки оказались такими большими, что перетаскивание на мобильном тормозило уже после добавления третьей фигуры.
В предыдущей статье я описал обходной путь, который был добавлен в .NET 6, чтобы инструменты EF Core, которые ранее полагались на существование определённых методов, таких как CreateHostBuilder, продолжали работать с новыми минимальными API хостинга.
В этой статье я рассмотрю связанное изменение, обеспечивающее работу интеграционного тестирования с WebApplicationFactory в .NET 6. WebApplicationFactory использовала тот же класс HostFactoryResolver, что и инструменты EF Core, но потребовалось ещё несколько изменений, которые я рассмотрю в этой статье.
Всем привет, сегодня поговорим о внедрении Dependency Injection (далее - DI) в Nuke и рассмотрим моё видение. Кто не знаком с Nuke вы можете ознакомиться или на официальном сайте или посмотреть вот эту презентацию, если коротко - то это очень удобная система автоматизации сборок, которая по факту консольное приложение на C#.
Совсем недавно мне пришлось разбираться с проблемами перформанса одного веб приложения. В процессе определения источника проблем возникали вопросы "сколько в среднем занимает вызов метода класса X", "как много данных приходит на эндпоинт Y", "как часто происходит flush в Z", и несколько стандартных вопросов при перформанс оптимизациях: "как мы потом узнаем что стало лучше", "насколько стало лучше", "было бы неплохо показать графики для демонстрации" и т.д. Так как некоторая часть работы была спрятана вне API endpoint-ов (background workers) и требовалась более детальная статистика для некоторых компонентов, стандартные средства перформанс мониторинга Application Insights не полностью покрывали все нужды. Для поиска ответов был необходим дополнительный набор инструментов мониторинга и после небольшого исследования были выбраны NET event counters в связке с уже применяемым на проекте Application Insights.
В этой статье я хочу финализировать все полученные знания об этом инструменте, о его конфигурации для Azure + Application Insights, а также порассуждать о том где и в каких сценариях этот инструмент применим. Статья может быть интересна всем NET разработчикам как общий обзор данной технологии, короткий гайд по ее конфигурации и обзор списка возможных сценариев ее применения.
Всего есть 3 типа жизни (ServiceLifetime) экземпляра:
Singleton - одиночка, создается один раз и используется во время использования всего процесса, метод .AddSingleton<T>().
Transient - временный, создается каждый раз при запросе его из провайдера, метод .AddTransient<T>().
Scoped - ограниченный, новый экземпляр создается в определённой области видимости (scope) в интерфейсе IServiceScope. Добавляется методом .AddScoped<T>().
Ссылка на картинку: https://stackoverflow.com/a/64776798
С выпуском Visual Studio 2022 вы можете использовать новый редактор Razor для локальной разработки ASP.NET Core с использованием MVC, Razor Pages и Blazor. Загрузите Visual Studio 2022 и обязательно обновите его до версии 17.0.2, чтобы получить последние обновления Razor. В статье подробнее о новых фичах и дальнейших планах на Razor.
Когда вы работаете с временем и датой в форме Razor Pages, очень важно выбрать элемент управления, который наилучшим образом будет удовлетворять требованиям вашей задачи. До HTML5 разработчики в значительной степени полагались на сторонние библиотеки с элементами выбора времени и даты. На сегодняшний день у них есть множество встроенных в браузеры опций, тем не менее они предпочитают наслаждаться многообразием вспомогательных технологий, доступных для современных браузеров. К ним относятся опции для управления и временем и датой, только временем или только датой, а также для выбора месяца или недели в году.
Изоляция CSS впервые появилась в .NET 5 для компонентов Blazor. Теперь она станет доступной и в Razor Pages (и в представлениях MVC) в .NET 6, который должен быть зарелижен в ноябре этого года. Ниже представлен краткий обзор того, как изоляция CSS работает в Razor Pages и какие проблемы она должна решать.
В этой статье я хочу поделиться несколькими нестандартными алгоритмами для быстрого возведения числа в степень, а также продемонстрировать их реализацию и сравнить их быстродействие в C++, C# и Java.
Сравнить точность алгоритмов можно прямо сейчас на этой странице.
В конце будет краткая памятка по тому, где и когда лучше применять какой из методов. При правильном выборе можно добиться увеличения скорости вычислений в 5 раз при погрешности ~1%, а иногда и вовсе без неё.
