Вы бы считали это одноэлементным / одноэлементным шаблоном?
Представьте, что в файле 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, и они объединены / совместно используются, поэтому в прямом смысле это не настоящий одиночка. Но в некоторой степени это действительно следует шаблону.
Итак, в ответ на вопрос, считаете ли вы это, по крайней мере, одноэлементным шаблоном?
Вы бы сказали, что его нельзя использовать? Вы бы не одобрили его использование? Вы бы сказали, что это плохая практика возможно, как настоящий синглтон.
Не могли бы вы увидеть какие-либо проблемы, которые могут возникнуть в результате такого сценария использования?
Или вы бы сказали, что это не настоящий синглтон, так что это нормально, и неплохая практика. Вы бы порекомендовали это как полуквази-синглтон, где требуется экземпляр для каждого запроса? Если нет, какой другой образец / предложение вы бы использовали / дали?
Вы когда-нибудь использовали что-нибудь подобное?
Я использовал это в прошлых проектах, но не уверен, стоит ли от этой практики держаться подальше. Однако в прошлом у меня никогда не было проблем.
Пожалуйста, поделитесь своими мыслями и мнениями по этому поводу.
Я не спрашиваю, что такое синглтон. И я считаю синглтон плохой практикой при неправильном использовании, что бывает во многих случаях. Это я. Однако я не это пытаюсь обсуждать. Я пытаюсь обсудить ДАННЫЙ сценарий.
хех, здорово. Мне нравится этот :)
Ответы 6
Я не .NET человек, поэтому воздержусь от комментариев по этому поводу, за исключением этой части:
Would you say its bad practice like a true singleton.
Настоящие синглтоны - это не плохая практика. Они УЖАСНО ПЕРЕСМОТРЕНЫ, но это не одно и то же. Я недавно прочитал кое-что (не могу вспомнить, где, увы), где кто-то указал на «хочу или нужно» против «могу».
«Нам нужен только один из них» или «Нам нужен только один»: ни одного сингла.
«У нас МОЖЕТ быть только один из них»: singleton
То есть, если сама идея иметь два таких объекта сломает что-то ужасным и незаметным образом, да, используйте синглтон. Это верно гораздо реже, чем думают люди, отсюда и распространение синглтонов.
Под «УЖАСНО ПЕРЕГРУЗИТЬ» я предполагаю, что вы имеете в виду «Неправильно используется в большом количестве кода и, таким образом, имеет плохую репутацию за то, что он не очень хорош для работы, для которой они не предназначены».
это хороший способ выразиться. Я отредактировал свой пост, чтобы немного прояснить свою позицию.
Под «УЖАСНО ПЕРЕГРУЗИТЬ» я имею в виду, что они используются людьми, которые просто думают: «О, мне нужен только один из них, поэтому я просто прикреплю его централизованно и использую статические методы для доступа к нему», а затем получу негибкий, непроверяемый код. Узор в порядке; используя его, «потому что» статические методы упрощают получение объекта «нет».
Да, я согласен. Я просто думаю, что это можно было бы выразить лучше :-)
Чтобы добавить к этому - когда я сказал: «Я что-то недавно прочитал», я понял сегодня, где это было, на случай, если кому-то будет до этого дело. Об этом говорилось в докладе Кевлина Хенни «Дюжина программиста» в JAOO на прошлой неделе. Он назвал это «Правило горца» - «Может БЫТЬ только один».
Синглтон - это объект, из которых МОЖЕТ БЫТЬ только один.
Объекты, которые сейчас есть один, не являются синглтонами.
Независимо от того, подходит ли это шаблону для печенья синглтона, он по-прежнему страдает теми же проблемами, что и синглтон:
- Это статическая, конкретная ссылка, и ее нельзя заменить на отдельное поведение или заглушить / имитировать во время теста.
- Вы не можете создать подкласс этого и сохранить это поведение, поэтому довольно легко обойти одноэлементную природу этого примера.
Спасибо, это скорее тот тип обсуждения / анализа, который я искал
Я отметил это как правильный ответ не потому, что это был абсолютно правильный ответ, я не думаю, что в этом вопросе он есть, но вы были одним из немногих, кто понял, что я пытался понять, и дал хороший ответ. спасибо еще раз.
Я бы сказал, что это определенно НЕ синглтон. Паттерны проектирования наиболее полезны как определения общих практик программирования. Когда вы говорите о синглтонах, вы говорите об объекте, в котором есть только один экземпляр.
Как вы сами заметили, существует несколько HttpApplications, поэтому ваш код не соответствует дизайну Singleton и не имеет таких же побочных эффектов.
Например, можно использовать синглтон для обновления курсов обмена валют. Если этот человек неосознанно воспользуется вашим примером, он запустит семь экземпляров, чтобы выполнить работу, для которой предназначен «только один объект».
Забудьте на мгновение синглтон.
У вас есть статические методы, возвращающие состояние приложения. Лучше берегись.
Если два потока обращаются к этому общему состоянию ... бум. Если вы живете на веб-сервере, ваш код в конечном итоге будет запускаться в многопоточном контексте.
Не могли бы вы уточнить? В этом суть вопроса - вызвать обсуждение и анализ ситуации. Одно лишь высказывание «Осторожно» никому ничего не говорит, и мы не можем извлечь из этого урок.
Спасибо! Я ценю, что вы обновили его. Однако я не уверен, как это может произойти, поскольку каждое приложение HttpApplication запускается в потоке для каждого запроса, поэтому два потока не должны иметь доступ, если я явно не создал другой поток. Может быть, я не совсем понимаю, что вы имеете в виду.
Поскольку вы говорите о веб-приложении, вам нужно быть очень осторожным, предполагая что-либо со статическими классами или этим типом псевдо-синглтона, потому что, как сказал Дэвид Б., они используются только в этом потоке. Проблемы могут возникнуть в том случае, если 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"];
}
}
Теперь, если вы думаете, что вам может потребоваться масштабируемый путь веб-фермы (многосерверного), то вышеуказанное не будет работать, поскольку кеш приложения не используется совместно между машинами.
Назовем его «AFewton». Тогда прекратите это дело.