Как правило, нет, это не будет проблемой.Исходя из упрощенного описания, нет возможности перехода.Однако, если вы выполняете какое-либо кэширование или иным образом сохраняете пользовательскую информацию в классе каким-либо образом (например, устанавливаете ivar), у вас могут возникнуть проблемы.Вообще говоря, если, кроме каких-либо зависимостей, которые вы вводите в конструктор, в противном случае класс можно сделать статическим и все еще работать, у вас все хорошо.Если вы делаете что-то внутренне, что помешало бы сделать класс статичным, то есть большая вероятность, что у вас утечка.
Тем не менее, если у вашего сервиса есть зависимости от сервисов с определенными областями, он должен быть сам по себе.С чем-то вроде «пользовательского» сервиса, есть большая вероятность, что вы будете полагаться на что-то вроде контекста EF или UserManager<TUser> и т. Д. Они ограничены, поэтому, если ваш сервис как одиночный, вы будете вынужденыиспользовать анти-шаблон сервис-локатор, и вы, скорее всего, будете делать что-то неэффективно в целом, пытаясь обойти зависимости, имеющие более короткий срок службы, чем сам сервис.В таком сценарии лучше всего сделать область обслуживания доступной, что позволит вам напрямую вводить зависимости области действия.
Похоже, существует наивная идея, что время жизни по умолчанию или предпочтительное время жизни должно быть единичным для таких вещей, как услуги, репозитории и т. Д.На самом деле, все наоборот: вы должны предпочесть ограниченную область, если нет веской явной причины поступать иначе.Например, если вы пытаетесь согласовать некоторый набор задач между потоками, используя что-то вроде SemaphoreSlim, это довольно очевидный сценарий, который потребовал бы времени жизни синглтона.Если вы не делаете что-то подобное, действительно требуется одиночное время жизни, используйте взамен ограниченное время жизни.