EpiServer CMS 5 R2: поставщики пользовательских страниц - правильный выбор?

Question

Я использую EpiServer CMS 5R2 для нового проекта. Мне было поручено создать CustomPageProvider для ссылки на существующее внутреннее хранилище, которое мы не можем контролировать. Однако, глядя на пример провайдера (XmlPageProvider), выясняется, что провайдер отвечает за ведение метаданных, например, необходимых EpiServer (из документа examples.xml):

<page id="10011" parent="10010" pagetypeid="3" versionid="1" security="Everyone:Read;Administrators:Create,Edit">
  <property name="PageGUID">35a988fe-2bc1-4e45-a41f-3a009a660551</property>
  <property name="PageTypeID">3</property>
  <property name="PageWorkStatus">4</property>
  <property name="PageFolderID">118</property>
  <property name="PageTypeName">[Public] Standard page</property>
  <property name="PageMasterLanguageBranch">en</property>
  <property name="PageLanguageBranch">en</property>
  <!---- SNIP! ---->
  <property name="Heading">A subpage</property>
  <property name="MainBody"><p>an external subpage</p></property>
  <property name="SecondaryBody"><p>second body</p></property>
  <property name="MetaAuthor">John Doe</property>
</page>

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

Итак, вопросы:

1. Является ли поставщик пользовательских страниц подходящим инструментом для работы?

2. Если да, то есть ли способ вернуть эту ответственность на EpiServer?

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

Очень ценится!

Роберт Стивенсон-Леггетт

Answer 1

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

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

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

Здесь довольно подробное обсуждение этого вопроса: Поставщики страниц и производительность EPiServer .

Answer 2

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

Answer 3

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

Answer 4

Получил это от моего вопроса на форуме EpiServer CMS: http://world.episerver.com/Forum/Pages/thread.aspx?id=27574&pageIndex=1

RE: Поставщики пользовательских страниц Опубликовать по: Йохан Бьёрнфот 3 февраля 2009 года, 13: 43: 28

Вам не нужно хранить мета информация в вашем внутреннем хранилище. Есть вспомогательные методы в PageProviderBase, например InitializePageData (устанавливает метаданные свойства) и SetPropertyValues (устанавливает мета и / или пользовательские свойства) это поможет вам с инициализацией Объекты PageData.

Итак, ответы на ваши вопросы:

1. Звучит так, будто PageProvider вполне подойдет для вашей цели.

2. Используйте InitializePageData для обработки метаданных (InitializePageData установит значения по умолчанию для мета-свойств например статус опубликован и тд). Если вы хотите установить купол другой значение свойства метаданных, чем по умолчанию, например статус (Опубликовать и т.д.) вы можете сделать это, позвонив SetPropertyValues ​​впоследствии.

3. Если необходимо хранить дополнительные данные вне резервного хранилища Есть несколько вариантов для этого (обычай таблица в БД, на основе файлов и т. д.). Который один из них зависит от вашего среда, тип данных для хранения и т.д.