Блог

Мы используем небольшое приложение (Flash), позволяющее посетителям определять свои предпочтения в отношении контента. Конечным результатом приложения является список элементов, который мы представляем пользователю как «Контент, который может вас заинтересовать» (представьте его как «Страницу, которую вы создали на Amazon»). Страница посетителя должна быть доступна как постоянная ссылка с использованием GUID и может быть перенаправлена на другой сайт, чтобы увидеть тот же контент. У нас нет логина или членства, поэтому все посетители анонимны.

Где и как я должен хранить список элементов для каждого посетителя?

В настоящее время мы рассматриваем возможность создания элемента в дереве содержимого для каждой страницы посетителя, который будет просто содержать ссылки на выбранные элементы содержимого, которые интересуют пользователя. Мы обеспокоены тем, что это приведет к большому количеству элементов контента, что может повлиять на производительность решения в целом.

Другими возможностями могут быть использование файловой системы (возможно, одного XML-файла) или SQL-поиска.

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

Мы сделали нечто подобное для клиента (за исключением того, что нам приходилось сохранять поисковые запросы, а не пользовательские настройки, но применяются те же принципы). У нас также было требование, что «страница посетителя должна быть доступна как постоянная ссылка и может быть перенаправлена на другой сайт, чтобы увидеть тот же контент» (хотя специально не используется GUID).

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

 http://website/pageThatYouBuilt.aspx?item1={guid}amp;item2={guid} //etc
  

конечно, в конечном итоге это приведет к созданию огромных URL-адресов, поэтому вы можете поместить идентификаторы guid в простой объект DTO

 public class State {
  public Guid Item1 {get;set;}
  public Guid Item2 {get;set;}
}
  

или даже

 public class State {
  public List<Guid> Items {get;set;}
}
  

Затем мы сериализовали этот «объект состояния» в строку. и вставил это в URL (querystring).
Мы использовали Protobuffer для достижения действительно эффективной сериализации (более короткие URL-адреса)

вот так:

 http://website/pageThatYouBuilt.aspx?state=GhIJgUc9EVb+k0cRnRABsX+ob8UyAA== 
  

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

для получения дополнительной информации о protofbuffer см.: http://code.google.com/p/protobuf-net/wiki/GettingStarted

кстати, это не вопрос, связанный с sitecore 🙂