Архитектурно заменить основной объект-одиночка контейнером IoC

Question

Мой вопрос касается архитектуры программного обеспечения в целом.

Рассмотрим пример:

У нас есть приложение-служба Windows.

Program.cs создает и запускает экземпляр класса MainService.

MainService наследуется от ServiceBase, поэтому реализует метод OnStart(string[] args).

Обычно, когдаЯ проектирую свое приложение, я бы сделал что-то подобное в методе OnStart:

MainSingletonObject.Initialize();

Инициализация будет читать данные конфигурации из app.config и создавать экземпляры необходимых классов, открывать хосты WCF (если есть) и т. д.

Это хорошая практика для запуска приложения-службы?Что бы вы посоветовали для улучшения дизайна?Где разместить контейнер IoC и зачем он мне нужен, если я делаю инъекцию зависимостей вручную.

Answer 1

Я бы использовал IoC на этапе начальной загрузки службы:

ServiceBase[] ServicesToRun;
            ServicesToRun = new ServiceBase[] 
                { 
                    new ServiceClass() 
                };
            ServiceBase.Run(ServicesToRun);

Вместо new ServiceClass я бы разрешил класс обслуживания через IoC. Таким образом, вы избегаете зависимости IoC в реализации сервиса. Если вам нужно создать с помощью внедрения новый объект изнутри вашей реализации, рассмотрите возможность предоставления услуги ITypeFactory, зарегистрированной в IoC, которая изолирует ваш код от конкретного контейнера, который вы будете использовать. В общем, вы можете измерить хороший дизайн в IoC, если вы тоже изолируете контейнер.

Answer 2

Singleton не должен зависеть от других, чтобы инициализировать его. Он инициализируется сразу после его использования.

Вот как бы я это сделал:

public class MySingleton
{
    private static readonly MySingleton _instance = new MySingleton();

    private MySingleton()
    {
        // ... read config
    }

    public static MySingleton Instance
    {
        get { return _instance; }
    }
}

Здесь static readonly гарантирует, что это ленивая нагрузка .