Пользователь
При начале разработки нового проекта у моей команды всегда появлялся вопрос, какую библиотеку выбрать для межсервисного взаимодействия? А какую использовать для походов в сторонние сервисы? В этой статье я постарался вкратце осветить различные обёртки над HttpClient.
Статья-туториал от ведущего разработчика "ITQ-Group" Александра Берегового, в которой мы рассмотрим применение обобщенного подхода при разработке WEB API.
Этот пост является продолжением цикла статей, рассказывающих об эволюции проекта nopCommerce. Вкратце поговорим о нововведениях .NET 7, поделимся своими мыслями на этот счет и рассмотрим замеры производительности, которые мы получили при обновлении нашего приложения.
Ходят слухи, что foreach быстрее for. А ещё ходят слухи, что for быстрее foreach. Пора разобраться, что быстрее!
Конвейер трудится изо всех сил, чтобы повысить производительность твоей программы. А злобные «if»'ы нагло врываются посреди его работы и всё портят!
На сколько полезен конвейер в современных ЭВМ? Как сильно мешаются ветвления в коде, которые ты написал? И как архитекторы процессоров сглаживают ущерб, который «if»'ы наносят по производительности программ?
Небольшая подборка интересных докладов с конференций для C# и .NET разработчиков за последние несколько лет.
На сегодняшний день в.NET существует несколько видов кодогенерации: новомодные Source Generators, компилируемые Expression Trees, динамические сборки и динамические методы. Каждый способ имеет свои области применения, плюсы и минусы.
В этой статье я хочу рассказать про динамические методы. Мы разберёмся как создавать их, как работает стековая машина и рассмотрим некоторые базовые операции Common Intermediate Language: работу с константами, математические и битовые операции, а также работу с аргументами методов и локальными переменными.
Сразу хочу сказать, что статья не содержит какого‑то хардкора и написана в большей степени для новичков. Если к теме будет интерес, постараюсь в следующей статье рассмотреть более сложные примеры (эта и так получилась достаточно длинной).
А вы никогда не задумывались, что async и await выглядят как-то инородно среди прочего C# кода? Больше нигде не встречается такого странного синтаксиса и таких модификаторов, кроме как в методах, работающих с Task и Task<T>.
А ещё интересно, сколько вообще стоит пользоваться async/await? И когда можно (нужно?) обходиться без них?
Я являюсь студентом по обмену из российского ГМИГ имени Трофима Лысенко (Главный Мурманский Институт Генетики). Учился на инженера-программиста и пол года назад был отправлен в Америку в качестве студента по обмену. Это у меня получилось благодаря двойному гражданству (я гражданин Ирана и России).
К нам на лекцию пришел один из разработчиков Microsoft и рассказал про .NET 10, подробнее в самом низу статьи под спойлером.
.NET 10 или как его теперь начнут называть .NET X - это новая версия .NET, которая выйдет уже в 2024 году. Большая часть этой статьи посвящена именно новым возможностям C# 13.
Почему .NET 10 и где .NET 9?
"У нас так принято." - Дословный перевод. Больше комментариев разработчик не дал.
Доброго времени суток! Меня зовут Васьен, я – начинающий backend разработчик, поставивший себе цель переучиться из экономиста в программисты с нуля. Обучение я начал в конце сентября прошлого года и на текущий момент выходит, что прошло ровно полгода с момента начала пути. Все нормально, я еще не вкатился и неизвестно, когда "вкачусь", я осознаю, что много чего осталось не изученным, в каких областях имею лишь очень поверхностные представления и просто продолжаю дальше учиться.
Так или иначе, разница между пониманием базовых вещей сейчас и тогда, на старте, огромная, и за столь небольшой временной промежуток успел набить пару шишек, получить какой-никакой опыт, понять в чем был не прав и могу предостеречь таких же попутчиков от повторения моих ошибок. Также данная статья является неким ответом на собственный вопрос из прошлой статьи, где я переживал за то, что имею так мало реализованных проектов, около пустой профиль на гитхабе и не знаю, как оценить свой прогресс. Заодно и советом начинающим, как эффективнее учиться, улучшать свои практические навыки программирования, понемногу заполняя свой гитхаб. Итак, какие ошибки я совершил за это время и в чем был не прав.
В процессе написания source generators для наших внутренних нужд я столкнулся с тем, что на большой кодовой базе обычные генераторы работают, скажем так, небыстро, существенно влияя на производительность IntelliSense в Visual Studio (который и так не то чтобы порхает как бабочка в таких условиях). Наткнувшись на описание более современного API — incremental generators, я обрадовался и обновил наши генераторы, чтобы они его реализовывали, однако ожидаемого прироста скорости не увидел (он был, но незначительный).
Мне никогда не нравилась многословность кода. Длинные и подробные названия упрощают работу с бизнес-логикой, но технические детали кода хочется держать краткими, чтобы они отвлекали на себя минимум внимания.
Одна из многословных конструкций .NET связана с деталями реализации асинхронности и обросла кучей мифов. Про неё спрашивают на собеседованиях, код-ревью, делают обязательной, добавляя в правила линтера. Это .ConfigureAwait(false), сопровождающий каждый await в коде.
В этой статье я расскажу, зачем нужен ConfigureAwait(false) и как обойтись без него.
Нейросети всё больше вливаются в привычный мир, пытаясь упростить нам жизнь. Тот же ChatGPT вызвал бурю обсуждений в интернете. Чат бот способен писать тексты, код, рефераты и песни. Он даже умеет искать ошибки в коде, но... хорошо ли он с этим справляется?
Строки в dotnet являются предназначенной только для чтения последовательностью Char-ов. Об этом явно написано в документации Microsoft, посвященной строкам. Там же в секции "Неизменность строк" сказано следующее: "Может показаться, что все методы String и операторы C# изменяют строку, но в действительности они возвращают результаты в новый строковый объект". Согласно документации, изменить строки нельзя, но жизнь не всегда согласуется с документацией, поэтому предлагаю взглянуть на способы, позволяющие изменять строки в dotnet (к тому же это иногда спрашивают на собеседованиях!).
Давным-давно, когда деревья были маленькие, дискеты большие, а трава зеленая, все писали на языках низкого уровня. В этих языках все было целыми числами. Переменные были числами, массивы были и структуры были просто адресами (числами) и смещениями (тоже числами). Даже если указывали тип данных, то он определял только размер памяти для значения.
В эти старые добрые времена было очень мало причин почему программа не могла продолжить работу. Например деление на ноль, неправильное обращение к памяти (например обращение по адресу равному нулю) или неправильная инструкция процессора (это когда уже совсем все плохо). Если что-то такое происходило операционная система без капли смущения грохала вашу программу.
Чтобы программа не грохалась, а выдавала осмысленное сообщение и давала возможность продолжить работу, надо было добавить проверку.
Распространенная проблема, которую я вижу в объектно-ориентированном проектировании:
* Волшебник — это разновидность игрока.
* Воин — это разновидность игрока.
* У игрока есть оружие.
* Посох — это разновидность оружия.
* Меч — это разновидность оружия.
Но прежде чем мы углубимся в детали, я просто хочу отметить, что на самом деле я не говорю здесь о чем-то специфичном для жанра фэнтезийных ролевых игр. Всё в этой серии одинаково хорошо применимо к корпоративным приложениями, но о волшебниках и воинах писать интереснее, так что вот.
Всем привет! Меня зовут Дядиченко Григорий, и я технический продюсер. В своём блоге в телеграм я периодически публикую задачки по Unity. Решение одной задачки получается слишком длинным, чтобы писать про него в блог. Поэтому я решил это оформить в статью. Задачка звучит так.
Вы решили сделать с друзьями свой скайрим. У вас пока в игре есть два вида оружия: молот и меч. Они отличаются уроном, прочностью и скоростью атаки. Плюс логикой атаки. Атака молота аое в круговой зоне. Атака меча бьёт до 3 ближайших противников. К вам пришёл катжит и за лунный сахар предложил купить у него схему архитектуры на картинке выше. Предложите решение лучше. В чём проблема данной схемы?
Почти каждый разработчик программного обеспечения работал с СУБД, по крайней мере каждый слышал о них. В мире существует множество способов для работы с базами данных и один из них - это ORM (англ. Oblect-Relational Mapping). Для разработчиков приложений, особенно бизнес-приложений, различного рода реализации данного способа стали в прямом смысле "спасательным кругом" в грубом мире работы с базами данных. Ещё начиная с .Net Framework компания Microsoft кидала такой круг разработчикам, который носил название Entity Framework (EF). И теперь, в .NET есть кроссплатформенная реализация старенького EF - Entity Framework Core (EF Core).
В EF Core существует несколько способов конфигурирования сущностей, все они рассмотрены в моей предыдущей статье - https://habr.com/ru/post/649647/. Лучший из них на мой взгляд - это реализация IEntityTypeConfiguration<>. Он позволяет отделить модель предметной области от хранилища, сделать структуру проекта более упорядоченной, а само решение более гибким. Далее по статье мы рассмотрим все преимущества данного способа. Итак, пришло время на не реальном реальном проекте разобраться наконец с этим способом описания отношений полей и сущностей.
Сделаем конфигурацию для магазина, который занимается продажей автомобилей. База данных у нас уже существует, нужно только "подружить" с ней наше решение на .NET. Будем считать, что структуру нашей будущей БД разрабатывал вменяемый человек, который соблюдал элементарные правила именования полей и т.п.
Имеем несколько таблиц Cars, EquipmentOptions, Makes, Models. Все они имеют поля, которые являются системными, имеют один и тот же тип и называются одинаково. Это поля Id, CreatedDateTime, UpdatedDateTime. Для описания этих полей, мы создадим базовую модель для будущих сущностей BaseEntity:
Если вы, как и я, уже являетесь большим поклонником Microsoft Entity Framework и хотели бы начать использовать его локально в своем мобильном приложении, с появлением .Net Maui на рынке, это стало возможным.
Небольшое замечание: для ускорения времени запуска мобильного приложения может быть лучше хранить данные, используемые во время загрузки, в локальном хранилище мобильного устройства в форме json. Но, когда дело дойдет до работы с большими локальными данными, использования фильтров, сортировки и т. д., EF определенно подойдет идеально.
Цель этой статьи — помочь избежать хлопот, связанных с поиском различных решений небольших проблем при реализации production-ready мобильной локальной базы данных и создании для нее миграций на компьютерах Windows и Mac. Исходный код примера приложения доступен по ссылке, указанной в конце. Как вы сможете увидеть, это будет типовой шаблон приложения Maui с добавленной логикой базы данных EF.