Если вам приходилось ломать голову над разгадкой таинственных неполадок SharePoint, а потом выяснялось, что они связаны с пользовательским кодом, значит описываемые далее проблемы вам хорошо знакомы. Разработка для 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:
- Полная страница.
- Надстраиваемая часть.
- Команды пользовательского интерфейса (лента или команды меню).
Эти три модели обеспечивают глубокую настройку на конкретное применение, в зависимости от проектируемого решения. Любое решение может содержать единственный компонент или компоненты различных типов, что обеспечивает безупречную интеграцию с платформой SharePoint.
При построении надстроек можно вернуться к стандартным приемам разработки и рассматривать надстройки как структуру из нескольких уровней, которые требуется запрограммировать. Каждая надстройка будет содержать пользовательский интерфейс, бизнес-логику и уровень доступа к данным. На сайте Microsoft MSDN приведены таблицы 2 и 3, где показано, что можно использовать в каждом случае.
![]() |
![]() |
Если изучить, какие компоненты и технологии следует использовать при разработке надстроек, вы сможете ускорить циклы проектирования и получить оптимальный программный код.
Наконец, основной вопрос: на что следует обращать внимание при разработке надстроек?
Благодаря модели SharePoint Add-in открывается так много возможностей проектирования, что не следует пытаться руководствоваться простым деревом принятия решений. Ниже перечислены факторы, которые следует принимать во внимание, проектируя архитектуру надстройки SharePoint.
- Функции, которые нужно сделать доступными, понимание особенностей использования.
- Наличие оборудования и ИТ-персонала для реализации данной модели.
- Целевая аудитория: внутри или вне компании.
- Имеющиеся в компании навыки разработки: опытному программисту. 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/.