А эта рекомендация по количеству ядер относится к физическим или логическим ядрам процессора, которые возвращает тот же Environment.ProcessorCount? По моим тестам всё же логическим, но возможно это истинно не для всех процессоров.
Здравствуйте, спасибо за Ваши вопросы по моей публикации!
Отложенное выполнение -> чтобы не занимать время выполнения основной операции. Совсем не хочется применять Fire-and-forget на огромное количество операций. Поэтому, чтобы не отправлять из каждой инстанции тысячи мелких запросов, консолидированные данные конкатенируются в один объект и отправляются одним запросом (что по итогу вышло быстрее как со стороны отправителя, так и потребителя).
Kafka я рассматривал в качестве решения, но мне хотелось снизить до минимума нагрузку на самописный брокер, поэтому дедупликация в том числе на стороне клиента, ведь масштабирование WebSocket'ов имеет некоторые общеизвестные ограничения https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-8.0.
Возможно, я ошибаюсь, или не так Вас понял? Вообще, у этого решения может быть много других сценариев использования, помимо вышеописанных.
Спасибо за интерес к моей публикации! Давайте разберемся подробнее:
1) Выброс исключения в приведенном примере имеет исключительно поведенческое назначение и осуществляется в "пользовательском коде". Он может быть описан на усмотрение разработчика как угодно, более того, его содержимое в данном случае абсолютно никак не влияет на дальнейшее поведение. У меня VS 2022 PRO v. 17.13.4 с конфигурацией Roslyn по умолчанию и подсказок по этому поводу нет / странно, правда?
2) Спасибо за замечание по поводу выброса исключения при внедрении DI. На самом деле, это базовая защита от ошибок со стороны разработчиков:
- Явное указание на зависимость: Проверка на null явно показывает, что внедряемая зависимость является обязательной для работы класса. Это улучшает читаемость кода и помогает другим разработчикам понять, какие зависимости необходимы для правильной работы класса. - Предотвращение скрытых ошибок конфигурации DI-контейнера: DI-контейнеры обычно настроены таким образом, чтобы выбрасывать исключение, если не удается разрешить зависимость. Но в некоторых случаях (например, при неправильной конфигурации или при использовании fallback-механизмов) контейнер может внедрить null вместо ожидаемой зависимости. Проверка на null в конструкторе служит дополнительной защитой от таких ситуаций. - Разработчик может передать null по ошибке, об этом можно прочитать здесь stackoverflow.com/a/72727192/11716490
3) В решении используется List<T>, что обеспечивает безопасность типов, то есть Вы случайно не добавите string к int, object лишь обобщённый пример, лучше было бы указать T?
Огромное спасибо за интерес к моей публикации! Давайте разберемся подробнее:
1) Статические функции (методы) в C# не могут содержать ссылки на объекты экземпляра (non-static). Это фундаментальное ограничение, зачем Вы предлагаете осознанно вводить его? Мне такой вариант не подходит.
2) Спасибо за замечание по поводу innerException. Выброс исключения в приведенном примере имеет исключительно поведенческое назначение и осуществляется в "пользовательском коде". Он может быть описан на усмотрение разработчика как угодно, более того, его содержимое в данном случае абсолютно никак не влияет на дальнейшее поведение. По поводу выброса с включением innerException в самом решении, у меня VS 2022 PRO v. 17.13.4 с конфигурацией Roslyn по умолчанию, подсказок по этому поводу нет / странно, правда?
А эта рекомендация по количеству ядер относится к физическим или логическим ядрам процессора, которые возвращает тот же
Environment.ProcessorCount? По моим тестам всё же логическим, но возможно это истинно не для всех процессоров.Здравствуйте, спасибо за Ваши вопросы по моей публикации!
Отложенное выполнение -> чтобы не занимать время выполнения основной операции. Совсем не хочется применять Fire-and-forget на огромное количество операций.
Поэтому, чтобы не отправлять из каждой инстанции тысячи мелких запросов, консолидированные данные конкатенируются в один объект и отправляются одним запросом (что по итогу вышло быстрее как со стороны отправителя, так и потребителя).
Kafka я рассматривал в качестве решения, но мне хотелось снизить до минимума нагрузку на самописный брокер, поэтому дедупликация в том числе на стороне клиента, ведь масштабирование WebSocket'ов имеет некоторые общеизвестные ограничения https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-8.0.
Возможно, я ошибаюсь, или не так Вас понял? Вообще, у этого решения может быть много других сценариев использования, помимо вышеописанных.
Спасибо за интерес к моей публикации! Давайте разберемся подробнее:
1) Выброс исключения в приведенном примере имеет исключительно поведенческое назначение и осуществляется в "пользовательском коде". Он может быть описан на усмотрение разработчика как угодно, более того, его содержимое в данном случае абсолютно никак не влияет на дальнейшее поведение. У меня VS 2022 PRO v. 17.13.4 с конфигурацией Roslyn по умолчанию и подсказок по этому поводу нет / странно, правда?
2) Спасибо за замечание по поводу выброса исключения при внедрении DI. На самом деле, это базовая защита от ошибок со стороны разработчиков:
- Явное указание на зависимость: Проверка на
nullявно показывает, что внедряемая зависимость является обязательной для работы класса. Это улучшает читаемость кода и помогает другим разработчикам понять, какие зависимости необходимы для правильной работы класса.- Предотвращение скрытых ошибок конфигурации DI-контейнера: DI-контейнеры обычно настроены таким образом, чтобы выбрасывать исключение, если не удается разрешить зависимость. Но в некоторых случаях (например, при неправильной конфигурации или при использовании fallback-механизмов) контейнер может внедрить
nullвместо ожидаемой зависимости. Проверка наnullв конструкторе служит дополнительной защитой от таких ситуаций.- Разработчик может передать null по ошибке, об этом можно прочитать здесь stackoverflow.com/a/72727192/11716490
3) В решении используется
List<T>, что обеспечивает безопасность типов, то есть Вы случайно не добавитеstringкint,objectлишь обобщённый пример, лучше было бы указатьT?Огромное спасибо за интерес к моей публикации! Давайте разберемся подробнее:
1) Статические функции (методы) в C# не могут содержать ссылки на объекты экземпляра (non-static). Это фундаментальное ограничение, зачем Вы предлагаете осознанно вводить его? Мне такой вариант не подходит.
2) Спасибо за замечание по поводу
innerException. Выброс исключения в приведенном примере имеет исключительно поведенческое назначение и осуществляется в "пользовательском коде". Он может быть описан на усмотрение разработчика как угодно, более того, его содержимое в данном случае абсолютно никак не влияет на дальнейшее поведение. По поводу выброса с включением innerException в самом решении, у меня VS 2022 PRO v. 17.13.4 с конфигурацией Roslyn по умолчанию, подсказок по этому поводу нет / странно, правда?