, что приведет к максимально быстрому доступу к значению строки myValue при исполнении.
Решение 2: перед сборкой отредактировать строку в csproj, в рантайме добавить строковую переменную, для инициализации значения которой привлечь механизм аттрибутов и рефлексию. Зачем?
По этому поводу могу сказать, что никто не мешает вам один раз на старте приложения зачитать все значения с подобных атрибутов в статическую структуру и использовать так же быстро как и в вашем «Решение 1». Просто в статье я посчитал ненужным писать уж столь очевидные вещи.
Редактировать исходники перед сборкой *сарказм* это вы круто придумали *сарказм*, будете руками перед каждым коммитом править эту строку, чтоб билдмашина правильно собрала? Дорогой друг, читайте внимательно первый абзац статьи. Да и просто статью в целом:
Первая мысль, которая меня посетила: перед билдом сгенерить файлик с константами по шаблону, но хотелось бы обойтись без привлечения тяжелой артиллерии шаблонизаторов.
Это адаптация app.config в dotnet core, но, как я ответил выше, мой поинт именно в том, что я не хочу конфигурировать эти значения. Я решаю задачу сохранения метаинформации в сборку. Т.е. моя задача и решение не связаны с конфигурацией приложения. Конфигурация отлично решается стандартными средствами типа appsettings.json
Мой поинт именно в том, чтобы зашить некоторую метоинформацию внутрь сборки. Мне не нужна возможность конфигурирования этой информации ни на каком этапе жизни приложения кроме шага сборки.
Не так быстро, друг. Не надо валить все в одну кучу. Я имел ввиду, что для модуля непосредственно битв миксовать TCP и UDP не есть хорошо. Но на уровне всей архитектуры бэкенда бессмысленно привязываться к единому протоколу.
Могу посоветовать разобрать сетевой код quake/doom. Там шикарное, на мой взгляд, решение проблемы гарантии доставки.
Если кратко, то сообщения бывают двух видов: важные и неважные. Все важные сообщения складируются в буфер и отправляются с каждым новым пакетом. Как только приходит подтверждение доставки, этот буфер чистится. Получается этакий брутфорс, который в довесок гарантирует что любое «важное» сообщение будет получено перед следующим «неважным».
По этому поводу могу сказать, что никто не мешает вам один раз на старте приложения зачитать все значения с подобных атрибутов в статическую структуру и использовать так же быстро как и в вашем «Решение 1». Просто в статье я посчитал ненужным писать уж столь очевидные вещи.
Если кратко, то сообщения бывают двух видов: важные и неважные. Все важные сообщения складируются в буфер и отправляются с каждым новым пакетом. Как только приходит подтверждение доставки, этот буфер чистится. Получается этакий брутфорс, который в довесок гарантирует что любое «важное» сообщение будет получено перед следующим «неважным».