Считаете ли вы это модель синглтон / синглтон?

Question

Представьте себе, что в файле Global.asax.cs у меня есть экземпляр класса в качестве частного поля. Скажем так:

private MyClass _myClass = new MyClass();

И у меня был статический метод в Global, называемый GetMyClass (), который получает текущее HttpApplication и возвращает этот экземпляр.

public static MyClass GetMyClass()
{
    return ((Global)HttpContext.Current.ApplicationInstance)._myClass;
}

Таким образом, я могу получить экземпляр текущего запроса httpapplication, вызвав Global.GetMyClass ().

Имейте в виду, что существует более одного (глобального) HttpApplication. Для каждого запроса есть HttpApplication, и они объединяются / разделяются, поэтому в прямом смысле это не настоящий singleton . Но оно в определенной степени следует шаблону.

Итак, как задан вопрос, рассмотрите ли вы это, по крайней мере, модель синглтона?

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

Не могли бы вы увидеть какие-либо проблемы, которые могут возникнуть из-за такого сценария использования?

Или вы бы сказали, что это не настоящий синглтон, так что все в порядке и неплохая практика. Вы бы порекомендовали это как полу-квази-синглтон, где требуется экземпляр для запроса? Если нет, какой другой шаблон / предложение вы бы использовали / даете?

Вы когда-нибудь использовали что-нибудь подобное?

Я использовал это в прошлых проектах, но я не уверен, стоит ли избегать этой практики. У меня никогда не было проблем в прошлом.

Пожалуйста, дайте мне ваши мысли и мнения по этому поводу.

Я не спрашиваю, что такое синглтон. И я считаю синглтон плохой практикой при неправильном использовании, что во многих-многих случаях. Это я. Однако это не то, что я пытаюсь обсудить. Я пытаюсь обсудить ЭТОТ сценарий, который я дал.

Answer 1

Вне зависимости от того, соответствует ли это шаблону печенья «Синглтон», он по-прежнему страдает теми же проблемами, что и синглтон:

• Это статическая, конкретная ссылка и не может быть заменена отдельным поведением или заглушена / осмеяна во время теста
• Вы не можете сделать это подклассом и сохранить это поведение, поэтому довольно просто обойти одноэлементную природу этого примера

Answer 2

Я не человек .NET, поэтому воздержусь от комментариев по этому поводу, за исключением этой части:

Вы бы сказали, что это плохая практика, как настоящий синглтон.

Истинные синглтоны не являются «плохой практикой». Они ужасно переоценены, но это не одно и то же. Я недавно прочитал что-то (не помню, где, увы), где кто-то указал - «хочу или нужен» против «можно».

«Нам нужен только один из них» или «нам нужен только один»: ни одного синглтона.

«У нас МОЖЕТ быть только один из них»: singleton

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

Answer 3

Синглтон - это объект, из которого МОЖЕТ БЫТЬ только один.

Объекты, из которых сейчас есть только один, не одиночные.

Answer 4

Поскольку вы говорите о веб-приложении, вам нужно быть очень осторожным, предполагая что-либо со статическими классами или псевдо-синглетами этого типа, потому что, как сказал Дэвид Б., они доступны только для этого потока. Проблема может возникнуть в том случае, если IIS настроен на использование более одного рабочего процесса (настроен в режиме «Web-Garden» с плохим названием, но также можно задать # рабочие процессы в machine.config). Предполагая, что на коробке установлено более одного процессора, тот, кто пытается настроить его производительность, обязательно включит его.

Лучшим примером для такого рода вещей является использование объекта HttpCache. По своей природе он уже поточно-ориентированный, но большинство людей по-прежнему ловят, что ваш объект также должен быть поточно-ориентированным (поскольку вы, вероятно, только собираетесь создать экземпляр, а затем со временем прочитать / записать многие его свойства ). Вот некоторый скелетный код, чтобы дать вам представление о чем я говорю:

public SomeClassType SomeProperty
{
    get
    {
        if (HttpContext.Current.Cache["SomeKey"] == null)
        {
            HttpContext.Current.Cache.Add("SomeKey", new SomeClass(), null,
                              System.Web.Caching.Cache.NoAbsoluteExpiration, TimeSpan.FromDays(1),
                              CacheItemPriority.NotRemovable, null);
        }
        return (SomeClassType) HttpContext.Current.Cache["SomeKey"];
    }
}

Теперь, если вы считаете, что вам может понадобиться путь масштабирования веб-фермы (для нескольких серверов), то вышеприведенное не сработает, поскольку кэш приложения не распределяется между компьютерами.

Answer 5

Забудьте синглтон на мгновение.

У вас есть статические методы, которые возвращают состояние приложения. Вам лучше остерегаться.

Если два потока обращаются к этому общему состоянию ... boom. Если вы живете на веб-сервере, ваш код в конечном итоге будет выполняться в многопоточном контексте.

Answer 6

Я бы сказал, что это определенно НЕ синглтон. Шаблоны проектирования наиболее полезны в качестве определения общих практик кодирования. Когда вы говорите о синглетонах, вы говорите об объекте, у которого есть только один экземпляр.

Как вы сами отметили, существует несколько приложений Http, поэтому ваш код не соответствует дизайну Singleton и не имеет тех же побочных эффектов.

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