Можно/нужно ли делать сервисы бизнес логики одиночками (Singleton) или статическими?

Например у меня есть сервисы ScannerService и UsersService. Первый отвечает за управление сканером на устройстве, второй получает данные из базы данных и содержит в себе объект DbContext (реализация UoW) для работы с базой данных. На разных формах используются разные сервисы, но эти два почти на всех. Стоит ли создавать новые объекта в каждой форме, или лучше использовать Singleton?
Можно ли объект, реализующий Unit of work, делать Singleton? Он вроде должен быть уничтожен после выполнения работы сервиса, в котором используется, но для меня не очевидно зачем его создавать по сто раз для каждого сервиса, если можно создать один раз и уничтожить после выполнения работы приложения.
Есть ли причины не делать сервисы статическими, если мне не нужно создавать их объекты, а нужно лишь использовать их функции, которые можно сделать статическими?

Ответ

Объект DbContext кэширует в себе все выбранные через него объекты (т.е. реализует не только Repository, UoW, но еще и Identity Map).
Соответственно, если вы косвенно сделаете его синглтоном, то ваше приложение
закэширует в себе все выбираемые через себя данные (всю базу) перестанет видеть изменения, вносимые в базу извне не сможет восстановиться после первой же ошибки валидации / сохранения (упал один SaveChanges - упадут и все следующие) будет дико тупить при сохранении из-за необходимости обнаруживать изменения в большом количестве объектов
Нет никаких причин делать сервисы или вообще любые другие классы статическими, если того явно не требует логика работы конкретных классов. Т.е. статическим синглтоном может быть какой-то глобальный кэш, который по определению должен быть один на один инстанс приложения. Или, например, класс, оборачивающий в себе доступ к стороннему сервису, и управляющий соединениями к нему (пул соединений SQL, мультиплексор StackExchange Redis и т.п.). И даже в этом случае единственность экземпляра должен обеспечивать контейнер, а не прямая статика.
Все остальное должно быть нестатическим, или, по крайней мере, не должно предполагать статичности/единственности зависимостей в своем коде.