Построение решений в SharePoint Online и локально

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

SharePoint поддерживает следующие варианты кода:
• Код полного доверия, упакованный в файлы WSP.
• Код клиентской объектной модели, упакованный в изолированные решения.
• Код, исполняемый на клиенте, javascript и jQuery, развернутый вручную или упакованный в песочнице или WSP-файлы полного доверия.
• Разработка надстроек (в прошлом — приложений). Если решение строится только для Office 365, то варианты с кодом оказываются более ограниченными из-за особенностей платформы. Далее список вариантов сокращается до следующих.
• Код клиентской объектной модели, упакованный в изолированные решения.
• Код, исполняемый на клиенте, javascript и jQuery, развернутый вручную или упакованный в песочнице.
• Разработка надстроек (в прошлом — приложений). Понимание ограничений и имеющихся возможностей позволит построить оптимальное решение.

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

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

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



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


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


Итак, мы видим, что даже в таком простом случае существуют различные подходы к созданию решения. Конечно, существует много других подходов, которые можно использовать для данного примера. В SharePoint всегда есть несколько вариантов создания решения, и не все они обязательно начинаются с «пользовательского кода». Безусловно, если нужно подготовить пользовательский код для локального Share Point или SharePoint Online, вы обратитесь к надстройкам (ранее известным как приложения). Теперь эти решения отделены от остальной части SharePoint, что позволяет повысить производительность, масштабируемость, безопасность и управляемость. Основная цель — избавиться от внутренней зависимости от кода, требующего полного доверия. Это означает, что службы и компоненты SharePoint будут свободны от влияния некорректного кода или простых утечек памяти.