Это - третья публикация в серии DDD и кодогенерация. (первая часть). В этой статье мы сгенерируем код класса для хранения всех данных запроса, код MVC контроллера. И наконец-то уберем рефлексию (но оставим наши типизированные атрибуты).
Я хочу поделиться практическим подходом, который позволяет переиспользовать ваш игровой код на C# из Unity на .NET-бэкенде — это даёт возможность верифицировать действия игрока, защищает от читерства и обеспечивает мгновенный отклик без лагов.
Я использую такую архитектуру в продакшене уже более 10 лет, и она отлично зарекомендовала себя как надёжное и эффективное решение. В этой системе один и тот же код выполняется и на клиенте (для мгновенной обратной связи), и на сервере (для авторитетной проверки).
Как это работает:
• Команды игрока мгновенно выполняются на клиенте.
• Та же команда вместе с хэшем состояния отправляется на сервер и повторно выполняется для верификации.
• Любые попытки изменить код или память клиента будут обнаружены и отклонены сервером.
• Игровая логика вынесена в .dll-плагин, который используется и в Unity-клиенте, и на .NET-бэкенде.
В статье есть полноценный пример на Unity («Connect Four»), открытый исходный код и подробное описание архитектуры.
Автоматическое тестирование, включая модульное и интеграционное, хорошо документировано и поддерживается множеством библиотек и платформ. Однако с ростом сложности приложений и увеличением количества пользовательских сценариев возникают новые проблемы, требующие современных инструментов.
В этой статье мы рассмотрим Scand Storm Petrel — инструмент для .NET-разработчиков, который автоматизирует однотипную работу по формированию и обновлению ожидаемых значений в тестах. Это особенно актуально при большом количестве тестовых сценариев или сложной структуре тестируемых объектов, что является неотъемлемой частью разработки современных приложений.
Сложная и тяжелая статья с непропорционально простым выводом. Вспомним фон Неймана, затронем процессорный кеш, поговорим про регистры и компиляторы. Тем, кому не хочется погружаться в детали, достаточно прочитать только Введение и Выводы.
Концепция этого цикла начиналась с простого переноса тайловых миров на F#. Однако в процессе его описания я основательно растёкся по древу, за счёт чего у нас образовался большой подготовительный этап из пяти глав про языковые фичи и прочую «фундаменталочку». Думаю, что с подготовкой закончено, поэтому сегодня мы обратимся непосредственно к тайловым мирам.
Но начнём мы практически с конца — с адаптации поиска пути. Это несложная задачка, но в процессе её решения мы успеем закрепить пройденный материал и по инерции заскочить в новый.
Все началось с того что к нам в офис приехал директор иногороднего филиала.
Он подошел ко мне и сказал примерно следующее:
«Я переписываюсь с генеральным директором с помощью mail.ru.
В переписке мы обсуждаем весьма щекотливые вопросы, связанные, например, с …, ну тебе лучше не знать…. Я бы не хотел чтобы эта переписка была доступна третьим лицам.»
Я, думаю, многие уже слышали о появившихся в .NET 6 Minimal API - легковесной замене контроллеров/MVC. Кто-то уже успел ознакомиться и задался вопросом: "Ваше API в 3 строчки, это, конечно, здорово, но как это будет работать в реальном проекте с сотнями эндпоинтов, кучей фильтров, аттрибутов, расширениями OpenAPI/Swagger и прочих радостях?"
В этой статье я хочу ответить на этот вопрос: пройдемся от основ, преимуществ, недостатков, и закончим нюансами работы и проблемами, которые обязательно возникнут при миграции с контроллеров на Minimal API в крупном проекте.
А забегая чуть вперед: если думаете, стоит ли переводить проект на Mini API, вот вам сразу полезная информация: они могут жить в проекте вместе, причем даже без дублирования инфраструктуры: не обязательно переводить все разом - подробнее под катом.
Бонусом, заменим SwaggerGen на реализацию OpenAPI от Microsoft.
За 13,5 лет я создал 12 опенсорс-проектов для платформы .NET и особое место среди них для меня занимает проект WebMarkupMin. Я не могу точно сказать, что мне больше всего нравится в нем: интересная исследовательская работа, лавры первопроходца на платформе .NET или не уходящая с годами актуальность.
В этой статье будет мало технических подробностей, потому что подобных статей о WebMarkupMin написано предостаточно. Здесь будет сделан акцент на разработке концепции опенсорс-проекта, его продвижении и взаимодействии с другими людьми.
В мире разработки приложений, будь то веб или десктоп, использование иконок является неотъемлемой частью пользовательского интерфейса. Векторные иконки предпочтительнее растровых, так как они масштабируются без потери качества. Одной из популярных коллекций векторных иконок является Bootstrap Icons, содержащая более 2000 готовых иконок. Хотя коллекция Bootstrap Icons доступна как npm-пакет bootstrap-icons и ориентирована на веб-разработку, её можно эффективно использовать в десктопных приложениях.
Создадим с нуля контрол BootstrapIcon для удобного использования двухцветных векторных иконок в приложениях на Avalonia/WPF. Сами изображения, в основном берем из SVG-файлов библиотеки bootstrap-icons, отсюда и название нашего контрола.
Туториал ориентирован на разработчиков, знакомых с Avalonia на базовом уровне. Основной упор в реализации контрола делается на Avalonia. Вариант для WPF, надеюсь, будет полезен для тех, кто переходит с WPF на Avalonia.
🔗 Полученные контролы BootstrapIcon для Avalonia и WPF с примерами использования размещены на GitHub.
👉 Продолжение следует...
Планируется публикация ещё пары туториалов, в которых будет пошаговое руководство для создания главного меню приложения и аналога ToolBar с использованием BootstrapIcon.
Простой вопрос: делая задачу, касающуюся API - вы чаще работаете с одним эндпоинтом, или пишете, условные, репозитории, которые используются сразу в нескольких эндпоинтах? Скорее всего, первое, тогда почему мы разбиваем проект по слоям, а не по фичам (эндпоинтам)?
Это видно в часто используемых нынче архитектурных подходах: Layered, Clean Architecture, Onion, и так далее. Не буду выделять что-то конкретное и объясню общую разницу в подходах:
Vertical Slice Architecture (VSA) строится вокруг каждого отдельного feature-слайса (эндпоинта, как самый простой пример), а не вокруг слоев.
То есть, если код относится к конкретному эндпоинту, мы не размазываем его по всему проекту в папках Commands/Services/Repositories/DTOs и т.п., а кладем в одно место, там где и будет находиться эндпоинт
Главный принцип - уменьшаем связанность между слайсами (фичами), увеличиваем связанность внутри слайса
Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, и так далее.
Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” - истинный, подлинный). В качестве доказательства может использоваться паспорт, для подтверждения личности в банке, либо ввод пароля на сайте.
Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.
В прошлом месяце я зарелизил ZLinq v1 — революционную LINQ-библиотеку, которая достигает zero allocation на структурах и дженериках. Она может похвастаться такими расширениями, как LINQ to Span, LINQ to SIMD, LINQ to Tree (FileSystem, JSON, GameObject и т.д.), drop-in replacement Source Generator для произвольных типов, поддержкой нескольких платформ, включая .NET Standard 2.0, Unity и Godot и на данный момент ZLinq имеет более 2000 звезд на GitHub.
Недавно передо мной встала интересная задача: организовать удалённый запуск сценариев в приложении на Unreal Engine с мобильного устройства.
Представим упрощённую ситуацию: на компьютере запущено приложение на Unreal Engine (назовём это инсталляцией), а у нас есть мобильное устройство, с которого необходимо передавать команды на эту инсталляцию. Это может быть как сложная мультимедийная инсталляция уровня змейка на фасаде здания, так и более простой пример — управление игровым персонажем с телефона, как с геймпада.
Пол года назад я начал копаться в исходном коде рослина, что бы понять, что такое красно-зеленые деревья, и вот это моя выжимка, и то что я бы хотел прочитать полгода назад.
Секретное оружие в .NET Core: Почему вы игнорируете мощь T-SQL?
Ваши LINQ-запросы становятся громоздкими? Производительность упирается в потолок? Возможно, вы упускаете нечто важное.
Эта статья — приглашение взглянуть на привычные инструменты под новым углом. Мы исследуем гибридный подход, который позволяет использовать весь потенциал Microsoft SQL Server, выходя за рамки стандартного взаимодействия через EF Core. Узнайте, как T-SQL может упростить сложные задачи, повысить производительность и сделать вашу архитектуру более гибкой.
Это не просто технический трюк, а переосмысление роли СУБД в современном приложении. Готовы узнать, как использовать "скрытые" возможности MSSQL и почему это может быть именно то, что нужно вашему проекту?
AabSemantics - простой, но функциональный движок для работы с семантическими сетями, написанный под .NET. Под катом - описание проекта и его базовых механик.
Хотел давно написать простенький парольный менеджер на C#, но было очень лень его вспоминать. Самые первые модели ChatGPT выдавали не работающий код, но несколько дней назад ChatGPT выдал практически идеально работающий код, правки были минимальны. Приложу ссылку на GitLab.
С выходом .NET 9 пакет Swashbuckle.AspNetCore выпилили из шаблона Web API. Это означает, что при создании нового приложения ASP.NET Core Web API у нас больше нет привычного зеленого пользовательского интерфейса Swagger для тестирования endpoint-ов. В статье — краткий разбор, почему это произошло, и обзор альтернативы Scalar.
В программирование меня изначально привело желание делать игры, но как-то так получилось, что за 16 лет карьеры я успел позанимался чем угодно, но не ими. Десктоп, фуллстек-разработка, бэкенд, мобильные приложения, в создания которых я влюбился с головой… Но желание делать игры не пропадало, а просто ждало где-то в сторонке — и спустя столько лет таки дождалось своего часа! Демоверсия уже загружена в Steam, и меня прямо таки распирает от желания рассказать… нет, не о самой игре, а о набитых шишках и о том, как меняется игровой процесс после столкновения с первыми плейтестами.
В этом посте описана одна из причин, по которой растёт расход памяти и возникают утечки, что при работе под Windows может приводить к исключениям OutOfMemoryException. Проблема может возникать после того, как приложение обновится с версии .NET 6 или ниже до .NET 7 или выше, но также встречается и в новых или необновлённых приложениях.
Мне не раз приходилось сталкиваться с данной конкретной проблемой, когда я работал в техподдержке. Поскольку я отвечаю, в основном, за веб-составляющую приложений, мне такие вещи встречались только в приложениях ASP.NET. Однако, эта проблема характерна не только для ASP.NET Core и может произойти в любом приложении под .NET.
Она может возникать в .NET 6 и ниже, но чётче проявляется и лучше просматривается в .NET 7 и выше. Дело в том, что в этих версиях .NET иначе, чем прежде, обращается с блоками памяти, отводимыми под кучи для сборщиков мусора. Разница такова: в .NET 6 и ниже (а также в .NET Framework) используются сравнительно крупные сегменты, для каждой кучи — свои. А в .NET 7+ для этой цели применятся более мелкие регионы, доступные для повторного использования. Если вы хотите подробнее почитать о сегментах и регионах, посмотрите пост от Маони Стивенс, которая занимается архитектурой сборщика мусора в .NET: https://devblogs.microsoft.com/dotnet/put-a-dpad-on-that-gc/
Кроме того, по-видимому, именно такие утечки возникают только в Windows. Я прихожу к такому выводу, изучив релевантный исходный код .NET. Правда, не поленитесь пролистать эту статью даже в случае, если ваше приложение хостится на какой-нибудь другой платформе.
