SharePoint — крупная платформа с богатыми функциональными возможностями. Приступая к построению решения, в первую очередь следует определить, что использовать. Если обратиться в Интернет, среди результатов поиска вы обнаружите много разных способов достичь цели: используя разнообразные схемы, готовые компоненты и специальный код на клиентской и даже серверной стороне. И все же в этих публикациях вы не найдете ответа на вопрос, какой подход будет наиболее эффективен в ваших условиях.

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

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

  • Типы контента.
  • Библиотеки и списки.
  • Макеты страниц.
  • Главные страницы.
  • Веб-части.

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

  • Код полного доверия, упакованный в файлы WSP.
  • Код клиентской объектной модели, упакованный в изолированные решения.
  • Код, исполняемый на клиенте, JavaScript и jQuery, развернутый вручную или упакованный в песочнице или WSP-файлы полного доверия.
  • Разработка надстроек (в прошлом — приложений).

Если решение строится только для Office 365, то варианты с кодом оказываются более ограниченными из-за особенностей платформы. Далее список вариантов сокращается до следующих.

  • Код клиентской объектной модели, упакованный в изолированные решения.
  • Код, исполняемый на клиенте, JavaScript и jQuery, развернутый вручную или упакованный в песочнице.
  • Разработка надстроек (в прошлом — приложений).

Понимание ограничений и имеющихся возможностей позволит построить оптимальное решение. Доступны и другие компоненты для иной функциональности, которая может оказаться полезной. Если вы строите решение с обобщением содержимого, создаете отчеты или просто объединяете содержимое в представления, то полезно соединить поиск с некоторыми другими компонентами бизнес-аналитики, такими как Power BI, если мы работаем с Office 365.

Если основное требование для нашего решения — предоставить механизм для простой подготовки сайтов для всех пользователей, без применения готового набора функций, то существует два подхода.

Чтобы облегчить выбор, приведу информацию о бизнес-требованиях: «Пользователи должны иметь возможность заполнить форму, которая обеспечит автоматическую подготовку подсайта. Эта форма должна создать главную запись в списке для подготовки сайта, которая будет содержать все необходимые значения. Форма должна требовать, чтобы конечный пользователь указал различные свойства и назначил таксономические значения. После того как запись добавлена, должен быть завершен процесс утверждения, после чего будет создан сайт».

Определив базовые требования, можно разделить функциональные возможности на категории.

Готовые к использованию

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

Пользовательские

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

Итак, мы видим, что даже в таком простом случае существуют различные подходы к созданию решения. Конечно, существует много других подходов, которые можно использовать для данного примера. В SharePoint всегда есть несколько вариантов создания решения, и не все они обязательно начинаются с «пользовательского кода».

Безусловно, если нужно подготовить пользовательский код для локального SharePoint или SharePoint Online, вы обратитесь к надстройкам (ранее известным как приложения).

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

Купить номер с этой статьей в PDF