2012-03-20 2 views
0

У меня есть система, которая позволяет пользователям планировать конференц-связь и приглашать людей, используя их адрес электронной почты. Это реализовано в ASP.net MVC 3, используя EntityFramework в шаблоне репозитория. Когда пользователь вошел в систему, я хочу отобразить список исходящих вызовов, которые они либо создали, либо были приглашены. В списке должны быть указаны данные о вызове, а также имя/адрес электронной почты организатора, в котором сохранено поле «Имя пользователя» и «Профиль» создателя вызовов.Оптимизация использования данных профиля

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

2 подхода я Рассматриваемый:

  1. магазин имя и адрес электронной почты организатора, когда создаются вызов. Существует вероятность, что эти детали будут обновлены организатором впоследствии, однако это может привести к отображению неправильной/устаревшей контактной информации.
  2. Загрузить все пользователи детали в хэш-таблицу и запрос к этому каждый раз - система в настоящее время в его первые дни и имеет несколько пользователей, однако может закончиться несколько тысяч (максимум)

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

+0

Когда вы включаете/включаете информацию о профиле с помощью вызовов, этого недостаточно? –

+0

Я использую поставщик членства .net, а не присоединяюсь к сущности в моем запросе. Если есть способ сделать это, тогда здорово? – Macros

+0

Хорошо, вижу. Нет, не элегантный способ сделать это. См. [This] (http://blogs.teamb.com/craigstuntz/2010/03/05/38558/). –

ответ

1

Вы можете кэшировать Профили пользователей (либо в памяти [System.Web.Caching/System.Runtime.Caching] или в каком-то более сложном кэше, как Redis) и аннулировать его, когда изменения профиля некоторых пользователей.

Конечно, вы аннулируете только измененную запись пользователя, а не весь кеш.

Таким образом, вам нравятся оба мира - попадание в память вместо базы данных для деталей профиля и по-прежнему иметь обновленные данные, если некоторые пользователи меняют свой профиль.

+0

Спасибо, у вас есть примеры? Я бы сделал это на application_start или это сеанс/пользователь басировал? – Macros

+0

К сожалению, это далеко за пределами этой области, чтобы попытаться представить образцы кода. По сути, он должен быть основан на пользователе (основанный на действии пользователя на самом деле - когда пользователь меняет профиль), а не в application_start или других местах приложения. В своем репозитории при попытке получить профиль пользователя вы сначала проверяете, находится ли он в кеше. Если так - подавайте его. Если нет - перейдите в БД, сохраните в кеше и верните результат. Когда пользователь меняет свой профиль, вы аннулируете (удаляете или обновляете) свою запись в кэш. –

+0

Данные, которые я буду кэшировать, - это просто хэш-таблица с ключом Guid и строкой (или двумя строками) в качестве значения. Этот подход действительно подходит для этого? Кажется, что это похоже на перехитрить. – Macros