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

#c_sharp #net #архитектура #шаблон_одиночка

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

Можно ли объект, реализующий Unit of work, делать Singleton? Он вроде должен быть
уничтожен после выполнения работы сервиса, в котором используется, но для меня не очевидно
зачем его создавать по сто раз для каждого сервиса, если можно создать один раз и уничтожить
после выполнения работы приложения.

Есть ли причины не делать сервисы статическими, если мне не нужно создавать их объекты,
а нужно лишь использовать их функции, которые можно сделать статическими?
    

Ответы

Ответ 1

Объект DbContext кэширует в себе все выбранные через него объекты (т.е. реализует
не только Repository, UoW, но еще и Identity Map).

Соответственно, если вы косвенно сделаете его синглтоном, то ваше приложение 


закэширует в себе все выбираемые через себя данные (всю базу)
перестанет видеть изменения, вносимые в базу извне
не сможет восстановиться после первой же ошибки валидации / сохранения (упал один
SaveChanges - упадут и все следующие)
будет дико тупить при сохранении из-за необходимости обнаруживать изменения в большом
количестве объектов


Нет никаких причин делать сервисы или вообще любые другие классы статическими, если
того явно не требует логика работы конкретных классов. Т.е. статическим синглтоном
может быть какой-то глобальный кэш, который по определению должен быть один на один
инстанс приложения. Или, например, класс, оборачивающий в себе доступ к стороннему
сервису, и управляющий соединениями к нему (пул соединений SQL, мультиплексор StackExchange
Redis и т.п.). И даже в этом случае единственность экземпляра должен обеспечивать контейнер,
а не прямая статика.

Все остальное должно быть нестатическим, или, по крайней мере, не должно предполагать
статичности/единственности зависимостей в своем коде.