Библиотека классов C # - шаблон проектирования Singleton - PullRequest
3 голосов
/ 12 декабря 2011

Фон / Вопрос:

Я довольно плохо знаком с шаблоном дизайна синглтона. Я однажды использовал его в веб-приложении (с помощью SO-сообщества):

public static AppGlobal Instance
{
    get
    {
        if (HttpContext.Current.Session != null)
        {
            HttpSessionState session = HttpContext.Current.Session;

            if (session["AppGlobalInstance"] == null)
            {
                session["AppGlobalInstance"] = new AppGlobal();
            }

            return (AppGlobal)session["AppGlobalInstance"];
        }
        else
        {
            return null;
        }
    }
}

Приведенная выше реализация имеет смысл для меня, поскольку экземпляр AppGlobal хранится в сеансе. Когда сеанс умирает, AppGlobal умирает. Что произойдет, если я использую тот же шаблон проектирования в библиотеке классов , который вызывается веб-приложением ? Например, пользователи запрашивают страницу, которая вызывает методы в DLL, которая не знает о сеансе. Будут ли сохранены данные, хранящиеся в одноэлементном экземпляре, через несколько вызовов?

private static readonly Singleton instance = new Singleton();
private Singleton() { }

public static Singleton Instance
{
    get
    {
        return instance;
    }
}

Дополнительная информация:

Вот что я пытаюсь выполнить: у меня есть веб-приложение, которое будет получать запросы XML от стороннего приложения. Этот XML скажет моему веб-приложению выполнить одну из трех вещей (или все три). Я хотел бы иметь одноэлементный экземпляр класса, который хранит данные, к которым могут обращаться несколько классов. Я хочу, чтобы экземпляр синглтона DIE после каждого запроса. Если вышесказанное не позволяет этого сделать, как лучше всего это сделать?

Примечание. Это веб-приложение запускается на одном сервере и никогда не запускается на ферме.

РЕДАКТИРОВАТЬ 1:

Основываясь на предложении ниже, я использовал System.Web.HttpContext.Current.Session для хранения своего экземпляра класса. Похоже ли это на правильный подход для синглтона, который будет уникальным для каждого сеанса (помните, я в библиотеке классов)?

    public static Ariba Instance
    {
        get
        {
            if (HttpContext.Current.Session != null)
            {
                HttpSessionState session = HttpContext.Current.Session;

                if (session["AribaInstance"] == null)
                {
                    session["AribaInstance"] = new Ariba();
                }

                return (Ariba)session["AribaInstance"];
            }
            else
            {
                return null;
            }
        }
    }

Ответы [ 3 ]

4 голосов
/ 12 декабря 2011

Он будет сохранен при нескольких вызовах, но есть одно предупреждение.Статические переменные находятся в области AppDomain, поэтому каждый раз, когда рабочий процесс IIS перезапускается, все данные, хранящиеся в статической переменной, будут потеряны.То же самое относится и к данным сеанса, если вы храните их «в процессе».

Если вы хотите, чтобы объект существовал только в течение HTTP-запроса, вы можете использовать свойство HttpContext.Items..

0 голосов
/ 12 декабря 2011

О!Если вы хотите использовать экземпляр PER REQUEST, почему бы вам не передать его в качестве параметра вызываемым методам или в качестве параметра конструктора для классов, для которых требуется xml.Я думаю, это будет лучший подход к дизайну.

0 голосов
/ 12 декабря 2011

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

Но в приложениях ASP.NET вам следует избегать использования Singletons. Вместо этого вы должны использовать объект Application. Основная причина этого заключается в том, что если вы будете использовать веб-ферму, то ваш синглтон больше не будет единичным для области приложения, а только на компьютере.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...