Каковы потенциальные подводные камни для единичных регистраций Io C для классов обслуживания без сохранения состояния? - PullRequest
0 голосов
/ 30 марта 2020

Это не шаблон проектирования синглтона GoF - мне известны причины, по которым он не используется.

Я был вовлечен в устаревший проект рабочего стола (C # / WPF), чтобы помочь очистить часть использования памяти и проблемы с производительностью. Одна из областей, на которую я обращаю внимание, - это управление жизненным циклом объектов в контейнере Io C (для любопытных DryIo C). Конкретно, это очень большое приложение, которое имеет множество небольших классов обслуживания без сохранения состояния (не одиночные или служебные классы stati c); например, что-то вроде этого:

public interface IImageIo
{
    void Save(Image img, string path);
    Image Load(string path);
}

public sealed class ImageIo: IImageIo { /* implementation */ }

Классы, подобные этому, регистрируются как переходные процессы и вводятся в конструктор как зависимости. Некоторые из этих классов часто используются в большом количестве компонентов и могут содержать десятки копий в памяти. То, что я думаю сделать, это сдвинуть регистрацию некоторых из этих классов в «синглтон», чтобы один и тот же экземпляр снова использовался.

Основной компромисс, который я вижу, состоит в том, что, регистрируя их как таковые, после их создания они будут жить в течение всего приложения - так что будет иметь смысл делать это только для объектов, в которых они хранятся для всего объекта. срок службы приложения менее важен, чем их пиковое использование в качестве переходных процессов.

Я обычно избегал жизненных циклов объектов с одним экземпляром, поэтому целью этого вопроса является проверка на предмет интуиции, чтобы выяснить, есть ли другие потенциальные проблемы, с которыми я сталкиваюсь. Я не знаю, или если это кажется разумным.

...