Пишу простое приложение на asp.net 2.0 (c#), которое хранит настройки зарегистрированных юзеров в и зависимости от этих настроек, прячет/показывает некоторые части веб-сайта, производит некоторые действия — в общем — используется и на мастер странице и в разных контролах, вложенных в нее.
Юзерские настройки могут динамически меняться в базе, поэтому, по идее, нужно перед каждой загрузкой страницы считывать настройки из БД и давать возможность доступа к нему различным объектам на этапе загрузки/инициализации контролов.
Как сделать так, чтобы за одну загрузку страницы один раз лезть за настройками в базу?
— Засовывать экземпляр класса, считывающего данные в Context?
— Инициализировать класс в master page?
— Session?
[skipped]
Я б сделал хранение данных как-нибудь в singletone и если возможно, изменения тоже через него (в том случае, если настройки меняются в самом приложении), тогда хранить реально данные в Application (если они для всего application одинаковые).
Юзеров, работающих с приложением — несколько тысяч.
Уместно ли использовать singletone в этом случае?
F>Я б сделал хранение данных как-нибудь в singletone и если возможно, изменения тоже через него (в том случае, если настройки меняются в самом приложении), тогда хранить реально данные в Application (если они для всего application одинаковые).
Здравствуйте, OldManAlex, Вы писали:
OMA>Юзеров, работающих с приложением — несколько тысяч. OMA>Уместно ли использовать singletone в этом случае?
А в чем может быть порьлема? Application получается сам по себе singletone в каком-то роде в рамках приложения, так что я не вижу проблем (это не говорит о том, что их нет )
Здравствуйте, OldManAlex, Вы писали: OMA>Пишу простое приложение на asp.net 2.0 (c#), которое хранит настройки зарегистрированных юзеров в и зависимости от этих настроек, прячет/показывает некоторые части веб-сайта, производит некоторые действия — в общем — используется и на мастер странице и в разных контролах, вложенных в нее. OMA>Юзерские настройки могут динамически меняться в базе, поэтому, по идее, нужно перед каждой загрузкой страницы считывать настройки из БД и давать возможность доступа к нему различным объектам на этапе загрузки/инициализации контролов.
Производительность стандартных Вас Profiles не устраивает?
Здравствуйте, OldManAlex, Вы писали:
OMA>Юзеров, работающих с приложением — несколько тысяч. OMA>Уместно ли использовать singletone в этом случае?
Не уместно: у коллекции Application плохая масштабируемость — используйте Cache. Лучше всего вообще не изобретать велосипед, а взять ORM, к примеру, NHibernate и использовать его кеширование (можно использовать обычное кеширование в памяти, а можно использовать ASP.NET кеш) — несколько XML-настроек и кеширование работает, почти ни строчки кода.
OMA>Юзеров, работающих с приложением — несколько тысяч.
Так как юзеров работающих с приложением много (хотя 1000 это не много), то я бы попытался не тратить ресурсы сервера и попробовал запихать все настройки в куки.
Не думаю что настроек много и их нельзя распихать по битовым флагам (фича включена/выключена).
Если куки нет, а юзер известен, то берем настройки из базы и ложим ему в куки.
Если же хранить на сервере: так как настройки уже хранятся в базе, то, ИМХО, лучший вариант хранить в сессии (именно для этого она и нужна .
Т.е. алгоритм такой:
1) получили запрос от нового юзера
2) залезли в базу достали настройки, положили в сессию
3) получили второй от него же
4) достали настройки из сессии.
Еще можно предложить комбинированный вариант (подходит когда частоиспользуемые настройки малы) :
часть настроек (самы используемые) помещаются в куки, а если нужны специфические "тяжелые" настройки, то лезем в базу и опять сессия.
P.S. C куками нужно быть внимательно: вдруг компом пользуется не только этот юзер, а несколько...
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, OldManAlex, Вы писали:
OMA>>Юзеров, работающих с приложением — несколько тысяч. OMA>>Уместно ли использовать singletone в этом случае? R>Не уместно: у коллекции Application плохая масштабируемость — используйте Cache.
по моемому у родного ASP.NET cache с масштабируемостью также плохо как и у Application R>Лучше всего вообще не изобретать велосипед, а взять ORM, к примеру, NHibernate и использовать его кеширование (можно использовать обычное кеширование в памяти, а можно использовать ASP.NET кеш) — несколько XML-настроек и кеширование работает, почти ни строчки кода.
Между запросами лучше бы не кэшировать. За время, прошедшее между HTTP запросами, юзерские настройки могут поменяться (например их ему можно поменять администратор системы). Поэтому, вопрос остается открытым — как все такм лучше все это безобразие запроектировать?
OMA>>>Юзеров, работающих с приложением — несколько тысяч. OMA>>>Уместно ли использовать singletone в этом случае? R>>Не уместно: у коллекции Application плохая масштабируемость — используйте Cache. C>по моемому у родного ASP.NET cache с масштабируемостью также плохо как и у Application R>>Лучше всего вообще не изобретать велосипед, а взять ORM, к примеру, NHibernate и использовать его кеширование (можно использовать обычное кеширование в памяти, а можно использовать ASP.NET кеш) — несколько XML-настроек и кеширование работает, почти ни строчки кода.
Куки, к сожалению, не подойдут. За время, прошедшее между несколькими входами юзера в приложение, его настройки могут поменяться (например их ему можно поменять администратор системы). ;-(
A>Так как юзеров работающих с приложением много (хотя 1000 это не много), то я бы попытался не тратить ресурсы сервера и попробовал запихать все настройки в куки.
Здравствуйте, OldManAlex, Вы писали:
OMA>Юзеров, работающих с приложением — несколько тысяч. OMA>Уместно ли использовать singletone в этом случае?
Если у тебя на каждого пользователя по десять килобайт — общий размер в памяти вряд ли превысит десятки мегабайт. Ну и никто не мешает организовать LRU-кэш.
Я конечно понимаю, что память нынче дешева, но зачем в промежутке между юзерскими запросами хранить ненужные данные в памяти? Особенно учитывая то, что юзер, скажем, может заходитиь раз в неделю...
C>Если у тебя на каждого пользователя по десять килобайт — общий размер в памяти вряд ли превысит десятки мегабайт. Ну и никто не мешает организовать LRU-кэш.
Здравствуйте, OldManAlex, Вы писали:
OMA>Я конечно понимаю, что память нынче дешева, но зачем в промежутке между юзерскими запросами хранить ненужные данные в памяти? Особенно учитывая то, что юзер, скажем, может заходитиь раз в неделю...
Так вот и теряют время на изобретение велосипедов.
Кеш может иметь так называемое "скользящее устаревание", к примеру, настройка в 1 минуту: если последний раз обращение было больше, чем минуту назад — объект из кеша выбрасывается, если на 59 секунде пользователь нажал F5, кеш продлил жинь его объекта снова на целую минуту вперед. И это, насколько помню, даже стандартный ASP.NET-кеш умеет. Ну а именно ваша проблема — минимизировать число запросов к БД — легко решается ORM-ами. Не пойму, в чем сложность взять книжку и прочитать, как организуются кеши в миру, зачем ломать голову, ожидая, что на нее упадет гениальная мысль, которая почему-то не упала тем, кто до вас уже всеми возможными способами решал подобные задачи?
OMA>За время, прошедшее между несколькими входами юзера в приложение, его настройки могут поменяться (например их ему можно поменять администратор системы). ;-(
И что администратор только и делает что меняет настройки пользователю? ИМХО это происходит раз в неделю/месяц не чаще.
Что случиться если пользователь зайдет под старыми настройками один или два раза? ИМХО ничего страшного это ведь не сайт "пентагона".
OMA>Как сделать так, чтобы за одну загрузку страницы один раз лезть за настройками в базу?
Если тебе нужен один экземпляр на запрос, то конечно клади настройки в контекст запроса. Только он живет ровно столько сколько сам запрос пользователя.
Это сделать не сложно:
public static string UserSettings
{
get
{
if (!HttpContext.Current.Items.Contains("UserSettings"))
{
HttpContext.Current.Items["UserSettings"] = GetSettingsFromDB();
}
return HttpContext.Current.Items["UserSettings"] as string;
}
}
Здравствуйте, OldManAlex, Вы писали:
OMA>Между запросами лучше бы не кэшировать. За время, прошедшее между HTTP запросами, юзерские настройки могут поменяться (например их ему можно поменять администратор системы). Поэтому, вопрос остается открытым — как все такм лучше все это безобразие запроектировать?
что значит не кешировать? сначала минимизировать количество запросов, потом не кешировать, так не бывает.
в asp.net 2 появилась возможность повесить обработчик на изменение таблиц.
Здравствуйте, OldManAlex, Вы писали:
OMA>Куки, к сожалению, не подойдут. За время, прошедшее между несколькими входами юзера в приложение, его настройки могут поменяться (например их ему можно поменять администратор системы). ;-(
A>>Так как юзеров работающих с приложением много (хотя 1000 это не много), то я бы попытался не тратить ресурсы сервера и попробовал запихать все настройки в куки.
Проверяйте не поменял ли администратор настройки для пользователя и на основе этого принимайте решение о актуальности пришедших coocies. Мне тоже решение с куки нарвится
)
.
