DAL, сеанс, архитектура кэша

Хранение данных в сеансе не является хорошей идеей, потому что:

1. Каждый пользователь получает отдельную копию одних и тех же данных — огромная трата серверной памяти.
2. IIS перезапустит сеанс, если вы заполните его слишком большим объемом данных.

Я рекомендую хранить таблицы данных в кеше. , а также заполнение каждой таблицы только при первом запросе, а не все сразу. Таким образом, если IIS начнет освобождать место в кеше, ваш код не пострадает.

Очень простой пример получения по запросу:

T GetCached<T>(string cacheKey, Func<T> getDirect) {
    object value = HttpContext.Current.Cache.Item(cacheKey);
    if(value == null) {
        value = getDirect();
        HttpContext.Current.Cache.Insert(cacheKey, value);
    }
    return (T) value;
}

EDIT: — Обновление вопроса

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

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

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

Я не думаю, что это хорошая идея хранить 1000 различных таблиц данных с 2000 записями в любом месте. Если запросы настолько динамичны, что один и тот же запрос за короткий промежуток времени является исключением, то кеширование не кажется хорошим вариантом.

Что касается опции распределенного кэша, я предлагаю вам проверить http://memcached.org . Распределенный кеш, используемый многими крупными проектами по всему миру.

Я знаю, что скоро Velocity, но пока я знаю, что ему нужна Windows Server 2008, и это пока что-то очень новое. Обычно продукты Microsoft хороши с версии 2.0 :-)

Храните справочники/словари и элементы, которые очень часто требуются вашему приложению в объекте Application или Cache; запрашивать базу данных для данных, которые зависят от роли пользователя.

--ИЗМЕНИТЬ--

Это ответ на ваш комментарий.

Обычно в любой системе, ориентированной на данные, запросы выполняются вокруг таблицы фактов (или таблиц, которые неизбежно запрашиваются); если у вас есть набор неизбежных таблиц, поэтому вы можете использовать Cache.Insert():

1. Загружать неизбежные таблицы при запуске приложения;
2. Загружать большинство запрашиваемых таблиц в кэш по запросу таблицы;
3. База данных запросов для наименее запрашиваемых таблиц.

Если у вас нет проблем с производительностью, пусть SQL справится со всем.

Хранить такое количество данных в Session — очень плохая идея. Каждый пользователь получит свою версию!

Если это общие данные (одинаковые для всех пользователей), рассмотрите возможность их перемещения в объект Application.