Сколько вы позволяете Sitecore (или другим CMS) управлять?

Question

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

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

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

Поначалу это звучало довольно ужасно. Я бы просто подумал, что вы будете использовать CMS для редактора контента. Я мог бы понять, что продукты - это предметы, если нужно, но все остальное я бы поместил в отдельный RDb, который привязан к Sitecore через идентификатор продукта. Это больше работы, но наверняка, если бы все было размещено внутри Sitecore, у вас могли бы быть гигантские проблемы с производительностью?

С другой стороны, если бы все это было размещено в вашей CMS, вам не пришлось бы иметь дополнительный слой данных, и вы, вероятно, могли бы широко использовать встроенное кэширование вашей CMS. Было бы намного проще позволить вашим редакторам утверждать / не одобрять рецензии, поскольку они могли бы просто управлять всем этим с помощью администратора Sitecore, вместо того чтобы создавать для него пользовательскую страницу.

Вы работали на сайтах, которые всегда делали это одним способом, или вы пробовали оба? Насколько успешно вы их нашли?

Answer 1

Я специально не использовал sitecore, но мой ответ основан на опыте umbraco и EpiServer.

Я пробовал оба, и в основном, это зависит.Если вам нужно часто запрашивать эти данные - они должны быть в пользовательской БД, потому что базы данных большинства CMS абстрактны и сложны для запроса, как и обычная база данных.Вы обнаружите, что пишете много стандартного кода, чтобы обойти ограничения, такие как неправильная типизация, пустые значения и т. Д. Это связано с тем, как типы / страницы документов CMS определяются пользователем, то есть пользовательскими свойствами.Однако, пройдя по этому пути, теперь вам нужно будет создать инструмент администрирования для этих пользовательских данных, который может или не может быть интегрирован в ваш CMS-сервер.Таким образом, вам нужно взвесить варианты здесь.

Некоторые предложения CMS (например, EpiServer) позволят вам управлять пользовательскими источниками данных из него, используя модель поставщика для представления реляционных или других данных (XML, вызов веб-службы)как будто это были страницы в CMS.

Это ваши основные соображения, вам решать, что именно подходит для вашего конкретного проекта.

Answer 2

Сайты, с которыми я работал, обычно используют микс.

Т.е.для коммерческого сайта у меня наверняка были бы все продукты, категории и так далее в Sitecore.Но тогда наличие таких вещей, как комментарии, оценки, обзоры и т. Д., Становится частью отдельной базы данных, привязанной к предмету.Обычно это имеет смысл, когда у вас много данных, что делает дерево контента в Sitecore слишком большим для правильной работы (т. Е. Вам придется создавать код, чтобы автоматически разбивать его на подпапки или другие приемы).

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

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

Но все это говорит о том, что Sitecore хорош в некоторых структурах данных.Как и типичное содержимое веб-страницы, структурированное как страницы и фрагменты.То есть.элементы, которые размещены не в обычной структуре сайта, а где-то еще и на которые ссылаются обычные страницы.Например, если есть несколько общих «блоков контента», которые можно использовать на нескольких страницах, но которые должны быть выбраны авторами контента, использование этих внешних элементов может быть хорошим решением.

Answer 3

Я использовал Sitecore CMS и проделал некоторую работу с Основами электронной коммерции Sitecore . Если вы собираетесь создать сайт электронной коммерции с помощью Sitecore, вам следует использовать основы электронной коммерции в качестве предварительно созданной структуры электронной коммерции на Sitecore. Продукты, цены, варианты доставки, платежи осуществляются в дереве контента Sitecore. Если вы хотите добавить отзывы клиентов, вы можете расширить шаблоны Sitecore для этого или подключить внешнюю базу данных, как вы упомянули, и связать их по GUID Sitecore. Вы можете управлять любым количеством ресурсов внутри Sitecore, поэтому необходимо знать объем своего сайта и рассчитывать на то, чем вы управляете. У вас будет несколько продуктов или сотни? Какое количество отзывов вы ожидаете? Несколько или тонн? У Sitecore есть известная проблема с производительностью, когда под элементом более 100 непосредственных дочерних элементов (например, элементов комментариев под продуктом), Sitecore работает менее эффективно для этого элемента. Я порекомендовал вам сообщить подробности вашего сайта на форуме SDN и получить прямую обратную связь от сертифицированных Sitecore разработчиков.