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

310

15 сентября 2017, 18:23

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

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

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

Answer 1

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

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

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

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

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