В этой статье мы заглянем под капот CLR (Common Language Runtime) и разберём как хранятся разные типы данных. Также поговорим о том, что такое стек и куча, и как они взаимодействуют. И в заключении рассмотрим, как происходит выделение памяти и разберем принципы работы сборщика мусора.
Давайте представим, что вам нужно создать класс для хранения данных пользователя. Сколько строк кода вы напишете? Конструктор, свойства, метод ToString(), сравнение объектов... А если добавится новое поле? Придется обновлять конструктор, метод Equals, GetHashCode — утомительная работа, которая не добавляет бизнес-ценности вашему приложению.
В этой статье мы разберем, как records меняют подход к написанию кода, и почему они должны стать вашим стандартным выбором для представления данных.
Это - вторая статья цикла про функцию ограничения скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей функции друг с другом) описание классов универсального компонента ограничения скорости .NET. Функция ограничения скорости обработки запросов в ASP.NET Core, которая является предметом рассмотрения всего цикла, базируется именно на этом универсальном компоненте.
Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.
Ну, а если вам пришлось разбираться (потому что эта функция не работает так, как вы ожидали) или, как мне, просто захотелось разобраться для себя, как работает функция ограничения скорости обработки запросов в ASP.NET Core - читайте дальше.
Здравствуйте. Меня зовут Валерий и я - кодоголиклюблю писать программы. А ещё я люблю не только писать свои программы, но и читать чужие.
Недавно мне довелось погрузиться в чтение кода функции ограничения скорости обработки входящих запросов к веб-приложению на ASP.NET Core. И в этом цикле статей я хочу поделиться найденным и понятым мной. Тем более, ещё в самом начале своих штудий я обнаружил, что эта тема на Хабре просто не рассматривалась никак - даже на уровне пересказа документации с сайта Microsoft (весьма скудной, кстати). А потому вот прямо сейчас я хочу заполнить этот пробел.
В этой статье мы не просто посмотрим синтаксис — мы поймём зачем это нужно и как работает под капотом. Мы пройдём путь от указателей на функции в C/C++ до современных лямбда-выражений в C#, разберёмся с делегатами и научимся использовать всю мощь функциональных возможностей языка.
В квартире стояла летняя жара. Впрочем, ненадолго: хозяин квартиры как раз привез мне кондиционер, и его пора было запускать.
Через несколько недель
Я писал на C# программу для распаковки gzip-файлов и неожиданно поймал странное исключение, из которого следовало, что архив поврежден.
Ситуация выглядела дико: ошибка намекала на поврежденный архив, хотя сам файл не выглядел реально битым. Сказать, что это напрягало
Асинхронное программирование в c# стало стандартом де-факто с выходом .NET FrameWork 4.5 и появление ключевых слов: async и await. В современном мире трудно представить приложение: API, десктопное приложение без асинхронных вызовов. Однако, мне стало интересно самому разобраться, что на самом деле происходит по капотом: как компилятор преобразует асинхронный код, что такое state machine и почему использование .Result/.wait() может привести к deadlock.
Сидя на очередном teams митинге с коллегами на французском, и в очередной раз понимая, что упускаю смысл совещания, ибо уровень этого самого французского оставляет желать лучшего, подумал, что надо что-то делать.
И так как их много, а меня — мало, делать что-то предстояло мне. Teams и прочие платформы, конечно, имеют опции на такой случай, но не просить же включать запись каждый раз.
Получилась небольшая программа, которая берёт воспроизводимый звуковой поток, делит его на фразы, через whisper распознаёт в указанный язык (проверял русский, английский, французский) и переводит.
UseCase - как организовать своё приложение с точки зрения бизнес-процессов, чтобы не погрязнуть в хаосе сервисов, контроллеров и разрозненной логики.
Domain-Driven Design (DDD) звучит как серебряная пуля. Когда мы начинаем проект на ASP.NET, идея четкого разделения на слои, изоляция бизнес-логики в домене и использование паттернов вроде Repository и Unit of Work кажется идеальной архитектурой.
Но есть один нюанс: магия DDD начинает испаряться ровно в тот момент, когда количество агрегатов (реестров) в проекте переваливает за 30. То, что было элегантным решением для CRM с 10 сущностями, превращается в бюрократический ад для ERP-системы или крупного маркетплейса.
В этой статье я разберу, почему классический DDD в ASP.NET (особенно в связке с Entity Framework Core) становится узким местом на масштабных проектах.
Эта статья про нюансы распознавания кириллицы в коде, и про волшебные файлы, которые не понимают, в какой они кодировке, и ломают работу в коде.
В этой статье разберём, как файл «притворялся» что он Macintoch, хотя был Windows-1251, и какую проверку пришлось из-за этого дописать поверх стандартного Encoding.GetEncoding(cdet.Charset);
В распределённых системах повторная доставка сообщений — не редкая аномалия, а штатный сценарий. В этой статье разберемся, как устроен паттерн «Идемпотентный потребитель» в .NET, где проходят реальные границы его надёжности и почему одних гарантий брокера недостаточно, когда обработчик затрагивает базу данных, кэш и внешние сервисы. Особенно полезно будет тем, кто проектирует событийные системы и хочет заранее убрать класс ошибок, которые обычно всплывают только под нагрузкой или при сбоях.
На собеседованиях мы слышим или говорим сами, что поиск в массиве медленнее, чем в хеш-таблице. Кто-то даже вспоминает, что поиск в массиве имеет линейную сложность или O(n), а в хеш-таблице — константную O(1). Но работает ли это на практике? Что, если есть ситуации, когда поиск в массиве оказывается быстрее? Давайте не будем торопиться с выводами.
В современном мире генерация изображений с помощью нейросетей стала возможна не только большим компаниям с суперкомпьютерами, но и рядовым пользователям с простым геймерским железом.
И возможно, кому-то захотелось не только самому пользоваться этими нейросетями, но и дать доступ к ним большому кругу людей, что может быть сопряженно с некоторыми трудностями.
В современном мире enterprise-разработки часто встречается необходимость реализации распределённых блокировок. Недавно у меня как раз возникла необходимость реализации распределённой блокировки, и я применил пакет RedLock.NET, о чём и хочу рассказать.
Однако когда я писал статью, как-то «слово за слово», она вылилась в сравнительный анализ RedLock.NET и других решений, которые я тоже рассматривал. Мне кажется, все описанные ниже очевидные и не очень решения будет вспомнить вполне уместно. Надеюсь, получится не так уж длинно и будет полезно для читателей.
Под катом вы не найдете откровений, но найдете размышления (для кого-то, возможно, очевидные) разработчика над задачей, которую все вроде знают, как реализовывать, но когда нужно реализовать, то все опять «подзабыли».
В этом гайде я покажу, как интегрировать возможности YandexGPT (в частности, генерацию текста и картинок) в ваш ASP.NET Core проект.
Дорогие гости, прошу, присаживайтесь. Сегодня в меню: DllImport по-домашнему, рагу из C# и C++, запечёные в NuGet-пакете x64 и ARM. Также будет предложена закуска в виде истории о безумствах ИИ. Bon appetit!
Интеграционные тесты любят все на словах, пока не доходит до окружения, зависимостей и плясок с подготовкой стенда. В статье разберем более практичный подход: как писать изолированные интеграционные тесты с Testcontainers, не превращая их в хрупкую конструкцию из моков и костылей. На примере PostgreSQL и .NET посмотрим, как собрать тестовую среду, которая ведет себя достаточно близко к реальности, но при этом остается воспроизводимой и управляемой. Тема не новая, а боль до сих пор вполне живая — так что давайте разбираться.
Pure.DI — это генератор кода для внедрения зависимостей (Dependency Injection), который работает на этапе компиляции. Pure.DI развивает идею «чистого DI»: вместо контейнера и рефлексии вы получаете обычный C#‑код, который создаёт композиции объектов. В этой статье — новые возможности, которые упрощают настройку композиций, делают корни гибче, а диагностику — понятнее.
В прошлых частях мы научились:
- делать кастомные сообщения (и поняли, что там есть подводные камни)
- использовать Custom и Must для сложной логики
Теперь новый челлендж. Проект растёт, валидаторов становится много. И вы замечаете, что одни и те же правила переезжают из класса в класс. Давайте-ка вынесем их.
