Sitecore: варианты хранения/запроса пользовательских данных, используемых sitecore CD

Question

Это (ниже) было общей проблемой/дебатом по большинству моих проектов sitecore.

Проблема:

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

Solutions:

Один из вариантов, чтобы решить эта проблема создает пользовательскую таблицу DB и использует Entity Framework для CRUD.

Другой вариант - сделать копию основной базы данных (в виде данных) и использовать Sitecore API для CRUD.

Преимущество 2-го варианта может быть из использования API коробки, документооборот и т.д.

Кто-нибудь сталкивался с этой проблемы и что лучший способ решить эту проблему?

Answer 1

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

---

Вариант 3: Пользовательские DB + Поставщик данных

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

Плюсы: - CD не зависит в пользовательской БД, которая является большим преимуществом по сравнению с опцией 1. - Если вам нужно сделать какое-либо преобразование в элементы, опубликованные вами, вы можете это же применить при импорте. (В случае, вы подключаетесь к внешнему/существующему источнику данных, который вы хотите преобразовать)

Для получения дополнительной информации ознакомьтесь с этим: http://www.sitecore.net/learn/blogs/technical-blogs/john-west-sitecore-blog/posts/2012/05/when-to-implement-data-providers-in-the-sitecore-aspnet-cms.aspx

Answer 2

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

Однако, когда требование не является мелочью, особенно в интерактивных сценариях, например, что вы упомянули, вы должны задать себе такие вопросы, как: «что, если позже клиент хочет, чтобы он был многоязычным или что, если им нужна какая-то статистика? и аналитики на результат? Не хочу ли я использовать такие вещи, как WFFM или Analytics? " В таких случаях вы можете подумать об этом и взвесить плюсы и минусы и возможные варианты масштабирования в будущем (потому что практически проекты sitecore предназначены не для небольших веб-сайтов). Например, при сборе большого количества данных вам обязательно нужны Lucene/Solr и Item Buckets.

К счастью, в последней версии Sitecore у вас есть опция MongoDB, которая является хорошим вариантом для сбора интерактивных данных и материалов, которые не являются хорошо структурированными и склонны к изменению структуры в будущем.

Edit:

Существует также инструмент ORM называется Glass Mapper, похожий на EF, если вы заинтересованы. В то время как EF отлично работает с SQL-сервером, Glass Mapper работает с репозиторием Sitecore Data таким же образом, но может привести к небольшим недостаткам производительности для вашего кода.