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

Хранилище шаблонов и методов Office Patterns and Practices (PnP) обслуживается специальной группой, включающей не только сотрудников Microsoft, но и ресурсы мирового сообщества, что обеспечивает актуальность и востребованность информационного материала.

Вот что можно прочитать об этом на сайте Microsoft: «Инициатива создания хранилища шаблонов и методов SharePoint/Office 365 (PnP) изначально была подготовлена в 2013 году группой консультантов Microsoft, работавших над переводом пользователей с выделенным Office 365 на мультиабонентский режим. Это потребовало преобразования целевых решений Trust Code Solutions для SharePoint в модель надстройки, но концепция PnP начала переходить и в другие области, включая API для Office 365, надстройки Office и унифицированные API. Сегодня инициатива PnP переросла в деятельность сообщества разработчиков с открытым исходным кодом с внутренними и внешними участниками. Заметим, что инициатива SharePoint/Office 365 Dev PnP не связана напрямую с официальной группой Patterns and Practices в Microsoft, которая больше сконцентрирована на общих вопросах разработки».

Для доступа к решениям и шаблонам перейдите на сайт http://dev.office.com/patterns-and-practices.А это ссылка на сайт GitHub, где размещаются все шаблоны: https://github.com/OfficeDev/PnP.

Типовые коды и примеры сгруппированы следующим образом:

  • PnP at dev.office.com — домашняя страница, откуда начинается поиск шаблонов и рекомендаций;
  • PnP Yammer Group — вопросы и обратная связь;
  • PnP at MSDN;
  • PnP videos на канале 9;
  • PnP at Docs.com — Docs.com;
  • PnP Sites Core Component — репозиторий GitHub;
  • PnP Core Component (JavaScript) — репозиторий GitHub;
  • PnP PowerShell — репозиторий GitHub;
  • PnP Partner Pack — повторно используемый стартовый комплект, отвечающий типовым корпоративным требованиям;
  • PnP Guidance — репозиторий GitHub;
  • PnP Office-Addins — репозиторий GitHub;
  • PnP Tools — репозиторий GitHub;
  • PnP Transformation — репозиторий GitHub;
  • PnP Provisioning Schema — репозиторий GitHub.

Как это применить

Очень долго мы были вынуждены самостоятельно искать правильные подходы к построению локальных и онлайн-решений. Теперь у нас есть готовые основные компоненты, которые можно использовать в качестве основы для создаваемых решений. Чтобы начать работу с примерами, необходимо установить базовый пакет путем ввода соответствующей команды Nuget в Visual Studio.

  • Для SharePoint 201:
Install-Package SharePointPnPCore2013
  • Для SharePoint 2016:
Install-Package SharePointPnPCore2016
  • Для SharePoint Online:
Install-Package SharePointPnPCoreOnline

Когда пакет будет установлен, компоненты станут доступными для любого из загружаемых шаблонов. Следующим шагом будет ознакомление с предоставляемой документацией (https://github.com/OfficeDev/PnP-Guidance/tree/master/articles).

Например, документация, посвященная фирменной символике и подготовке сайтов (https://github.com/OfficeDev/PnP-Guidance/blob/master/articles/Branding-and-site-provisioning-solutions-for-SharePoint.md), содержит основные рекомендации, составляющие обширное хранилище сведений обо всем, что требуется для SharePoint в локальной или «облачной» реализации. В документации даны ссылки на другие шаблоны и компоненты кодов, которые могут помочь в построении решений.

Выбрав нужные компоненты, можно загрузить код непосредственно с GitHub, а затем при необходимости внести в него изменения и начать использовать. Стандартный типовой проект выглядит примерно так, как показано на экране 1.

 

Пример стандартного типового проекта
Экран 1. Пример стандартного типового проекта

Компоненты типового проекта Documentation сгруппированы по папкам и содержат классы. cs. Проект может включать:

  • AppModelExtensions. Методы расширений — конструкция. Net, позволяющая расширить существующий тип с помощью дополнительных методов.
  • Entities («Сущности»). Простые классы, используемые для получения более сложных объектов с помощью методов расширений.
  • Enums. Классы перечислений для различных компонентов.
  • Extensions. Эта папка содержит методы расширений (http://msdn.microsoft.com/en-us/library/bb383977.aspx), не относящиеся к SharePoint, например методы, способные помочь в манипуляциях со строками.
  • Utilities. Служебные (вспомогательные) классы для конкретных компонентов в рамках проекта.

Загрузив любой из шаблонов по ссылке https://github.com/OfficeDev/PnP/tree/master/Samples, можно ознакомиться с возможностями проекта и основного кода. В качестве примера рассмотрим шаблон для создания семейства сайтов с использованием CSOM и надстройки Provider Hosted (размещено у поставщика): https://github.com/OfficeDev/PnP/tree/master/Samples/Provisioning.SiteCollectionCreation.

Основной проект разбит на проект Web и проект надстройки SharePoint. Проект Web содержит схему кода, показанную на экране 2.

 

Пример схемы кода для проекта Web
Экран 2. Пример схемы кода для проекта Web

Открыв код, переходим на страницу файла кода по умолчанию (см. экран 3). Есть и другие коды для других частей проекта, но этот является основным и демонстрирует выбранный Microsoft алгоритм действий. Возникает вопрос: зачем мне этот код, если я сам могу написать такой же? Подлинная причина применения PnP-компонентов связана с тематическими областями, такими как методы расширения, платформа для удаленных заданий по расписанию, управление аутентификацией, платформа подготовки сайтов и особые команды PnP в PowerShell (см. экран 4).

 

Пример страницы файла кода по умолчанию
Экран 3. Пример страницы файла кода по умолчанию

 

Тематические области
Экран 4. Тематические области

Как можно заметить, возможности, которые открываются с помощью этих компонентов, затрагивают все области, относящиеся к разработке для SharePoint или Office. Где это может пригодиться? Именно там, где следует использовать оптимальные методы или поддерживаемые Microsoft подходы к созданию приложений и разработке для SharePoint в локальной системе или в составе Office 365.

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