Если вам приходилось ломать голову над разгадкой таинственных неполадок Share­Point, а потом выяснялось, что они связаны с пользовательским кодом, значит описываемые далее проблемы вам хорошо знакомы. Разработка для SharePoint за последние годы заметно изменилась. От нее не отказались, но модель корректируется с целью повышения эффективности усилий программистов. Назначение всей модели App Model (лучше сказать, Add-in Model) — обеспечить не только масштабирование программного кода, но и такую же развязку с платформой SharePoint, как было в прошлом. На самом деле подход прост: переместите код из SharePoint, разместите его изолированно, а затем установите связь с SharePoint с использованием клиентского объектного кода; кода, исполняемого на клиенте, и, конечно, API-интерфейсов REST. В результате становится возможным более аккуратный подход к обмену данными с SharePoint. Администраторы ИТ и SharePoint будут чувствовать себя гораздо увереннее благодаря безупречной работе правильной, грамотно обслуживаемой среды SharePoint. А разработчики больше не смогут обвинить во всех бедах «неверный код». На мой взгляд, это ситуация, выигрышная для всех.

Однако не все задачи можно решить в рамках данной модели. Существуют элементы кодирования, которые необходимо выполнять в соответствии со стандартом WSP с использованием кода, требующего полного доверия. Поэтому не следует предполагать, что Add-in Model позволит выполнять все действия точно так же, как прежде. Теперь важно очертить круг возможностей новых способов, а затем проектировать старыми методами только компоненты, которые необходимо тесно интегрировать, например поставщик утверждений.

Примите за правило: подход к разработке должен основываться на принципе ««облако» в первую очередь». Такое проектирование подготовит вас к неизбежному переходу в «облако» в будущем. Office 365, и в частности SharePoint Online, в любом случае ограничит круг ваших усилий по программированию с помощью модели Add-in Model, так как нельзя развернуть файлы WSP, требующие полного доверия. По-прежнему доступны устаревшие, но действующие решения типа Sandbox Solutions.

Локальная версия поддерживает как старые файлы WSP, так и новый подход Add-in. Чтобы надстройки были полезны в локальных условиях, нужно соответствующим образом настроить среду SharePoint. Стандартный подход предполагал настройку App Web, веб-приложения, в котором хранятся изолированные ресурсы кода, обменивающиеся данными с SharePoint.

Прежде чем углубиться в эту тему, важно разобраться в существующих моделях.

Надстройки, размещенные в SharePoint

Эти типы надстроек почти полностью состоят из компонентов SharePoint, сохраненных в App Web. Вся бизнес-логика для них реализована с использованием объектной модели JavaScript (JSOM). Это позволяет задействовать все функции создания, чтения, обновления и удаления. Надстройки, размещенные в SharePoint, могут обращаться к данным и ресурсам, находящимся вне Add-in Web, с помощью любого из двух методов, безопасно обходящих политику SOP браузера: специальной междоменной библиотеки JavaScript или особого класса WebProxy JavaScript. Используя эти методы, надстройка, размещенная в SharePoint, может работать с данными на хост-сайте, его родительской подписке или в любом месте в Интернете.

Надстройки, размещенные у поставщика

Любой элемент SharePoint, который может использоваться в надстройке, размещенной в SharePoint, может работать и в надстройке, размещенной у поставщика. Главное различие между двумя подходами заключается в том, что надстройка, размещаемая у поставщика, использует удаленные компоненты, такие как веб-приложение, служба или база данных, из фермы SharePoint или системы SharePoint Online. Для этого можно задействовать различные технологии: Windows или Linux, IIS или Apache, MSSQL или MySQL, C# или PHP. Благодаря такой широте охвата удается сочетать разные технологии и упростить интеграцию с приложениями, не функционирующими на базовой платформе Microsoft. Элемент «поставщика» в надстройках таких типов — это владелец кода. Им можете быть вы, продавец или другой поставщик. В любом случае основные компоненты приложения размещаются где-то в другом месте; затем добавляются компоненты SharePoint, соединяющие все части в единое целое. Вкратце все приведенные выше сведения о различиях надстроек представлены в таблице 1.

 

Различия вариантов надстроек

Варианты разработки

Существует три способа использовать или представить надстройку SharePoint внутри SharePoint:

  1. Полная страница.
  2. Надстраиваемая часть.
  3. Команды пользовательского интер­фейса (лента или команды меню).

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

При построении надстроек можно вернуться к стандартным приемам разработки и рассматривать надстройки как структуру из нескольких уровней, которые требуется запрограммировать. Каждая надстройка будет содержать пользовательский интерфейс, бизнес-логику и уровень доступа к данным. На сайте Microsoft MSDN приведены таблицы 2 и 3, где показано, что можно использовать в каждом случае.

 

Удаленные компоненты в надстройках, размещенных у поставщика

 

Компоненты SharePoint: варианты для каждого уровня

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

Наконец, основной вопрос: на что следует обращать внимание при разработке надстроек?

Благодаря модели SharePoint Add-in открывается так много возможностей проектирования, что не следует пытаться руководствоваться простым деревом принятия решений. Ниже перечислены факторы, которые следует принимать во внимание, проектируя архитектуру надстройки SharePoint.

  1. Функции, которые нужно сделать доступными, понимание особенностей использования.
  2. Наличие оборудования и ИТ-персо­нала для реализации данной модели.
  3. Целевая аудитория: внутри или вне компании.
  4. Имеющиеся в компании навыки разработки: опытному программисту. NET удобнее работать при размещении у поставщика, а программист SharePoint, вероятно, предпочтет модель размещения в SharePoint.

В том или ином виде модель SharePoint Add-in обязательно займет место в арсенале разработчика. Но нельзя не одобрить идею строить решения, которые в меньшей степени полагаются на платформу SharePoint и должны устанавливаться непосредственно в ферме, веб-приложении или коллекции сайтов.

Я подготовил три статьи, в которых изложены дополнительные сведения о применимости размещаемых приложений. Их можно найти по следующим ссылкам:

  • https://www.helloitsliam.com/2014/11/07/sharepoint-2013-hosted-apps-do-they-really-work-part-1/;
  • https://www.helloitsliam.com/2014/11/07/sharepoint-2013-hosted-apps-do-they-really-work-part-2/;
  • https://www.helloitsliam.com/2014/11/07/sharepoint-2013-hosted-apps-do-they-really-work-part-3/.