Сразу же сообщу, что в данной публикации не сравниваются Fullstate и Stateless парадигмы построения серверов. Также отсутствует какая-либо агитация в пользу Fullstate. Мы исходим из ситуации, в которой мы приняли решение, что для конкретного проекта сервер ASP.NET должен между запросами не только хранить какие-то статические данные, но и возможно выполнять какую-то полезную работу.
При этом мы, разумеется, хотим использовать всю мощь DI-контейнера .NET!
Создание REST API является основной частью многих проектов разработки. Выбор для создания таких проектов широк, но если вы разработчик на C#, варианты будут весьма ограничены. API на основе контроллеров были наиболее распространенными в течение долгого времени, но .NET 6 меняет эту ситуацию, предлагая новую возможность.
Сегодня в этой статье я хочу поделиться личным опытом работы и решением конкретного кейса. Как подружить сервер авторизации на протоколе OpenId Connect и веб-приложения, накрытых обратным прокси-сервером YARP.
Иногда хочется автоматически создавать текстовые файлы, подставляя в шаблоны значения каких-то полей. Например, это могут быть исходники классов-хелперов на основе какого-то интерфейса, какие-то отчеты в XML, которые хотя и можно сгенерировать полностью программно, но на практике это может быть достаточно трудный для сопровождения код. Наверное, те, кто сталкивался с такой потребностью, смогут дополнить этот список. Приведу для примера задачу с хелперами.
Если мы не используем EF (такое случается), то нам нужно как-то устроить загрузку объектов из базы данных. Вариант: берём DataSet, делаем ему SomeDataAdapter.fill(...), а из него берём данные для строительства нужных объектов. При этом класс, который умеет заполнять DataSet, не знает, для объектов какого класса он это делает. Абстракция, низкая связанность, всё хорошо.
Однако, мы ждём, пока заполнится DataSet, только после этого можем начать
Небольшой обзор стандартных средств запуска бэкграунд-задач в аспнет приложениях — что есть, чем отличается, как пользоваться. Встроенный механизм запуска таких задач строится вокруг интерфейса IHostedService и метода-расширения для IServiceCollection — AddHostedService. Но есть несколько способов реализовать фоновые задачи через этот механизм (и ещё несколько неочевидных моментов поведения этого механизма).
Можно считать это продолжением публикации Кастомный JsonConverter: уменьшаем связность и экономим ресурсы. Там при рассмотрении списков верхнего уровня упор был сделан на десериализацию из JSON. Но чтобы что-то десериализовать, нужно сначала это сериализовать. Посмотрим, чем нам может помочь возможность сериализации IAsyncEnumerable<T> объекта.
Рассматриваем некоторые возможности, которые нам предоставляет кастомный JsonConverter.
Привет! Я Антон Антонов, Full Stack Developer. Расскажу, как обрабатываю необработанные исключения в 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
