Size: a a a

var chat = new Chat();

2021 July 21

VL

Vova Lantsov in var chat = new Chat();
+, для первого я как раз писал свой IServiceProvider, все интерфейсы обернув в моки и дав им какую-то тестовую логику
источник

VL

Vova Lantsov in var chat = new Chat();
Но это трудно делается
источник

AS

Andrii Shcherbyna in var chat = new Chat();
Я ревьювил пару проектов и видел, что некоторые имплементят механизм, который ходит по транзитивным референсам и собирает в одну общую кучу классы, которые содержат bindings. Этот механизм просто в тестах подключали в OneTimeSetUp в базовом классе и всё. Он был гибким и переиспользовался во всех микросервисах.
источник

AS

Andrii Shcherbyna in var chat = new Chat();
Грубо говоря у тебя в солюшине 5 модулей, у каждого есть класс, который в ServiceCollection добавляет bindings. Механизм их находил и подгружал
источник

н

назови меня клоуном... in var chat = new Chat();
грустное сообщение
источник

АК

Антон Камышенков... in var chat = new Chat();
Почему ConfigureAwait(false) идет не по умолчанию, если его рекомендуют использовать при вызове асинхронных методов ?
источник

Ɖ

Ɖrēw in var chat = new Chat();
Это отличный вопрос
источник

Ɖ

Ɖrēw in var chat = new Chat();
Видимо потому что раньше была другая мода на поведение по умолчанию, другие фреймворки и требования к ним
источник

Ɖ

Ɖrēw in var chat = new Chat();
А потом из-за совместимости так пошло
источник

VL

Vova Lantsov in var chat = new Chat();
Обратная совместимость
источник

VL

Vova Lantsov in var chat = new Chat();
Все так привыкли, смысл менять
источник

Ɖ

Ɖrēw in var chat = new Chat();
Та дело не в привыкли
источник

Ɖ

Ɖrēw in var chat = new Chat();
А чтобы после миграции на новую версию ничего не ебнулось
источник

VD

Vitaly Deev in var chat = new Chat();
источник

VD

Vitaly Deev in var chat = new Chat();
Из статьи: Отсюда можно сформулировать общее правило: если вы пишете код уровня приложения, не используйте ConfigureAwait(false).

Не очень часто использую его. Да и не в одной статье читал, что это нужно либо при создании библиотек, либо в каких-то редких случаях
источник

Ɖ

Ɖrēw in var chat = new Chat();
Это не отвечает на изначальный вопрос автора вопроса
источник

VD

Vitaly Deev in var chat = new Chat();
Из той же статьи
Когда использовать ConfigureAwait(false)?

Это зависит от того, реализуете ли вы код уровня приложения или код библиотеки общего назначения.

При написании приложений обычно требуется некоторое поведение по умолчанию. Если модель приложения/среда (например, Windows Forms, WPF, ASP.NET Core) публикует специальный SynchronizationContext, почти наверняка этому есть веская причина: значит, код позволяет заботиться о контексте синхронизации для правильного взаимодействия с моделью приложения/средой. Например, если вы пишете, обработчик событий в приложении Windows Forms, тест в xUnit, или код в контроллере ASP.NET MVC, независимо от того, опубликовала ли модель приложения SynchronizationContext, вам нужно использовать SynchronizationContext при его наличии. Это значит, если используются ConfigureAwait(true) и await, обратные вызовы/продолжения отправляются обратно в исходный контекст — все идет как нужно. Отсюда можно сформулировать общее правило: если вы пишете код уровня приложения, не используйте ConfigureAwait(false)
источник

VD

Vitaly Deev in var chat = new Chat();
Этим и отличаются библиотеки общего назначения. Они являются универсальными отчасти потому, что их не волнует среда, в которой они используются. Вы можете использовать их из веб-приложения, из клиентского приложения или из теста — это не имеет значения, так как код библиотеки является агностическим для модели приложения, в которой он может быть использован. Агностический также означает, что библиотека не будет делать что-либо для взаимодействия с моделью приложения, например, она не будет получать доступ к элементам управления пользовательского интерфейса, потому что библиотека общего назначения ничего о них не знает. Так как нет необходимости запускать код в какой-либо конкретной среде, мы можем избежать принудительного вызова продолжений/обратных вызовов к исходному контексту, и мы делаем это, используя ConfigureAwait(false), что дает нам преимущества в производительности и повышает надежность. Это приводит нас к следующему: если вы пишете код библиотеки общего назначения, используйте ConfigureAwait(false). Вот почему каждый (или почти каждый) await в библиотеках среды выполнения .NET Core использует ConfigureAwait(false); За несколькими исключениями, которые скорее всего являются багами, и будут исправлены. Например, этот PR исправил отсутствующий вызов ConfigureAwait(false) в HttpClient.

Конечно это не везде имеет смысл. Например, одним из больших исключений (или, по крайней мере, случаев, где нужно подумать) в библиотеках общего назначения является случай, когда эти библиотеки имеют API, которые принимают делегаты на вызов. В таких случаях, библиотека принимает потенциальный код уровня приложения от вызывающей стороны, что делает эти допущения для библиотеки ”общего назначения" весьма спорными. Представьте, например, асинхронную версию метода Where LINQ: public static async IAsyncEnumerable<T> WhereAsync(this IAsyncEnumerable<T> source, Func<T, bool> predicate). Должен ли predicate вызываться в исходном SynchronizationContext вызывающего кода? Это зависит от реализации WhereAsync, и это причина, по которой он может решить не использовать ConfigureAwait(false).

Даже в особых случаях придерживайтесь общей рекомендации: используйте ConfigureAwait(false) если вы пишете библиотеку общего назначения/app-model-agnostic код
источник

VD

Vitaly Deev in var chat = new Chat();
Если коротко, то зависит от ситуации
источник

Ɖ

Ɖrēw in var chat = new Chat();
В пятом дотнете кстати интересно
источник