SharePoint — крупная платформа с богатыми функциональными возможностями. Приступая к построению решения, в первую очередь следует определить, что использовать. Если обратиться в Интернет, среди результатов поиска вы обнаружите много разных способов достичь цели: используя разнообразные схемы, готовые компоненты и специальный код на клиентской и даже серверной стороне. И все же в этих публикациях вы не найдете ответа на вопрос, какой подход будет наиболее эффективен в ваших условиях.
Исторически при построении решений использовались либо полностью готовые компоненты, программный код на клиентской стороне для извлечения и оформления внутренних или бизнес-данных, настраиваемый управляемый код или сторонние компоненты. Как правило, разработчикам приходится задействовать элементы каждого подхода.
В SharePoint возможны различные варианты построения решений. Если используются готовые компоненты, то основными строительными блоками будут следующие.
- Типы контента.
- Библиотеки и списки.
- Макеты страниц.
- Главные страницы.
- Веб-части.
Если требуется построить полностью развертываемое решение, масштабируемое как локально, так и в сети, то предпочтителен упакованный код. SharePoint поддерживает следующие варианты кода.
- Код полного доверия, упакованный в файлы WSP.
- Код клиентской объектной модели, упакованный в изолированные решения.
- Код, исполняемый на клиенте, JavaScript и jQuery, развернутый вручную или упакованный в песочнице или WSP-файлы полного доверия.
- Разработка надстроек (в прошлом — приложений).
Если решение строится только для Office 365, то варианты с кодом оказываются более ограниченными из-за особенностей платформы. Далее список вариантов сокращается до следующих.
- Код клиентской объектной модели, упакованный в изолированные решения.
- Код, исполняемый на клиенте, JavaScript и jQuery, развернутый вручную или упакованный в песочнице.
- Разработка надстроек (в прошлом — приложений).
Понимание ограничений и имеющихся возможностей позволит построить оптимальное решение. Доступны и другие компоненты для иной функциональности, которая может оказаться полезной. Если вы строите решение с обобщением содержимого, создаете отчеты или просто объединяете содержимое в представления, то полезно соединить поиск с некоторыми другими компонентами бизнес-аналитики, такими как Power BI, если мы работаем с Office 365.
Если основное требование для нашего решения — предоставить механизм для простой подготовки сайтов для всех пользователей, без применения готового набора функций, то существует два подхода.
Чтобы облегчить выбор, приведу информацию о бизнес-требованиях: «Пользователи должны иметь возможность заполнить форму, которая обеспечит автоматическую подготовку подсайта. Эта форма должна создать главную запись в списке для подготовки сайта, которая будет содержать все необходимые значения. Форма должна требовать, чтобы конечный пользователь указал различные свойства и назначил таксономические значения. После того как запись добавлена, должен быть завершен процесс утверждения, после чего будет создан сайт».
Определив базовые требования, можно разделить функциональные возможности на категории.
Готовые к использованию
Список SharePoint будет использоваться для хранения записи создания сайта. Будет определен пользовательский тип контента, содержащий все необходимые столбцы сайта, в том числе таксономические значения для маркировки на сайте. Вновь созданный поток работ будет привязан к списку, поэтому, когда добавляется элемент, отправляется уведомление для одобрения. После одобрения процесс завершается и создается сайт на основе свойств, введенных в первоначальную форму.
Пользовательские
Создается специальная форма с использованием стандартного программного кода. Можно избрать любой подход — на стороне клиента или сервера, что позволяет добавить записи списка, а также получить форму с богатым набором функций.
Итак, мы видим, что даже в таком простом случае существуют различные подходы к созданию решения. Конечно, существует много других подходов, которые можно использовать для данного примера. В SharePoint всегда есть несколько вариантов создания решения, и не все они обязательно начинаются с «пользовательского кода».
Безусловно, если нужно подготовить пользовательский код для локального SharePoint или SharePoint Online, вы обратитесь к надстройкам (ранее известным как приложения).
Теперь эти решения отделены от остальной части SharePoint, что позволяет повысить производительность, масштабируемость, безопасность и управляемость. Основная цель — избавиться от внутренней зависимости от кода, требующего полного доверия. Это означает, что службы и компоненты SharePoint будут свободны от влияния некорректного кода или простых утечек памяти.