Выбор правильного набора API в SharePoint
Сведения о нескольких наборах API, включенных в SharePoint, в том числе для серверной объектной модели, различных клиентских объектных моделей и веб-службы REST или OData.
Факторы, определяющие, какой набор API нужно использовать
Доступ к платформе SharePoint можно получить с помощью нескольких наборов интерфейсов API. Какой из них использовать, зависит от следующих факторов:
- Тип приложения. Возможные варианты включают, помимо прочего, следующие, которые не являются взаимоисключающими категориями: надстройка SharePoint, веб-часть на странице SharePoint, приложение Silverlight, работающее на клиентском компьютере или клиентском мобильном устройстве, ASP.NET приложение, предоставляемое в SharePoint с помощью IFrame, JavaScript, запущенный на странице сайта SharePoint. страница приложения SharePoint, приложение Microsoft платформа .NET Framework, работающее на клиентском компьютере, скрипт Windows PowerShell и задание таймера, выполняемое на сервере SharePoint.
- Ваши навыки. Вы удивитесь, но в SharePoint можно создавать приложения, не вникая особо в программирование для SharePoint. Можно сразу приступить к разработке приложений для SharePoint, имея опыт работы с одной из следующих моделей программирования:
- JavaScript
- ASP.NET
- REST или OData
- .NET Framework
- Windows Phone
- Silverlight
- Windows PowerShell
- Устройство, на котором выполняется код. Можно использовать сервер фермы SharePoint, внешний сервер (например, облачный сервер), клиентский компьютер и мобильное устройство. В этом разделе предлагается обзор различных наборов интерфейсов API, предоставляемых в SharePoint. На рисунке 1 показано, какие наборы интерфейсов API можно использовать для разработки каждого из 13 стандартных приложений для SharePoint. В большинстве случаев для этого доступны несколько интерфейсов API.
Рис. 1. Выбранные типы расширений SharePoint и наборы интерфейсов API для SharePoint
В таблице ниже представлены рекомендации о том, какой набор API использовать для списка выбранных стандартных проектов расширений SharePoint. В оставшихся разделах статьи описаны различные наборы интерфейсов API.
| Что нужно сделать | Какой интерфейс API подойдет |
|---|---|
| Создать веб-приложение ASP.NET, выполняющее операции создания, чтения, обновления и удаления (CRUD) данных SharePoint или внешних данных, подключаемых в SharePoint через внешний тип контента Службы Microsoft Business Connectivity Services (BCS), с использованием брандмауэра. | Клиентская объектная модель JavaScript. |
| Создать веб-приложение ASP.NET, выполняющее операции CRUD с данными SharePoint или внешними данными, подключаемыми в SharePoint с использованием внешнего типа контента BCS, не вызывая SharePoint через брандмауэр. | Клиентская объектная модель .NET Framework или Silverlight, а также конечные точки REST или OData. |
| Создать веб-приложение LAMP, выполняющее операции CRUD с данными SharePoint или внешними данными, подключаемыми в SharePoint с использованием внешнего типа контента BCS. | Конечные точки REST и OData |
| Создать приложение для Windows Phone, выполняющее операции CRUD с данными SharePoint. | Клиентская объектная модель для мобильных устройств. |
| Создать приложение для Windows Phone, использующее службу push-уведомлений (Майкрософт), чтобы оповещать мобильное устройство о событиях в SharePoint. | Клиентская объектная модель для мобильных устройств и серверная объектная модель. |
| Создать приложение для iOS или Android, выполняющее операции CRUD с данными SharePoint. | Конечные точки REST и OData |
| Создать приложение .NET Framework, выполняющее операции CRUD с данными SharePoint. | Клиентская объектная модель .NET Framework. |
| Создать приложение Silverlight, выполняющее операции CRUD с данными SharePoint. | Клиентская объектная модель Silverlight |
| Создать приложение HTML или JavaScript, выполняющее операции CRUD с данными SharePoint. | Клиентская объектная модель JavaScript. |
| Создать Надстройка Office, совместимое с SharePoint. | Клиентская объектная модель JavaScript. |
| Создать пользовательскую команду Windows PowerShell. | Объектная модель сервера |
| Создать задание таймера. | Серверная объектная модель. |
| Создать расширение центра администрирования. | Серверная объектная модель. |
| Создать единую фирменную символику для всей ферме SharePoint. | Объектная модель сервера |
| Создать пользовательскую веб-часть, страницу приложения или пользовательский элемент управления ASP.NET. | Объектная модель сервера Важно! Если функции, которые вы планируете предложить клиентам, не рассчитаны на администрирование с помощью SharePoint за пределами семейства веб-сайтов, то вместо использования серверной объектной модели рекомендуем создать надстройку SharePoint, включающую удаленное веб-приложение ASP.NET с необходимыми настраиваемыми веб-частями и пользовательскими элементами управления. Обратите внимание на первые две строки этой таблицы. |
Серверная объектная модель
Серверная объектная модель управляемых классов содержит самый большой набор интерфейсов API. На уровне SharePoint Foundation 2013 в ее состав входят классы и элементы, обеспечивающие программный способ управления базовым сайтом, и структура списка SharePoint Foundation. Большинство из этих классов находятся в пространстве имен Microsoft.SharePoint . Кроме того, вы можете расширить почти каждый компонент SharePoint Foundation с помощью серверной объектной модели, включая рабочие процессы, оповещения, веб-части, базовый поиск и службы Microsoft Business Connectivity Services (BCS). Серверная объектная модель также содержит расширенный набор интерфейсов API, чтобы обеспечить расширение возможностей системы администрирования и безопасности SharePoint Foundation, в том числе резервного копирования, диагностики работоспособности фермы, ведения журнала, управления веб-приложениями и фермой, обновления версии, развертывания, кэширования и настройки Windows PowerShell.
На уровне SharePoint добавляется намного больше классов для программирования управления корпоративным информационным содержимым (ECM), профилей пользователей, таксономии, расширенного поиска и других функций SharePoint.
Вы можете использовать LINQ to Objects для запроса любой коллекции IEnumerable в памяти, но поставщик LINQ to SharePoint позволяет напрямую запрашивать списки в базах данных контента SharePoint. Строго говоря, этот поставщик недоступен для любого другого набора API, описанного в этом разделе; однако в большинстве других существуют способы использования синтаксиса LINQ.
Сборки, определяющие встроенные серверные классы, устанавливаются в глобальный кэш сборок каждого сервера при установке SharePoint. Когда программирование выполняется для серверной объектной модели, сборки устанавливаются как решения ферм в глобальный кэш сборок.
Примечание.
Вместо изолированных решений для SharePoint теперь рекомендуем разрабатывать надстройки SharePoint, но изолированные решения все еще можно устанавливать в семействах веб-сайтов SharePoint. Сборки этих решений остаются в пакете, пока они не используются. При использовании они временно устанавливаются в папке на сервере. Дополнительные сведения см. в разделе Где развернуты сборки в изолированных решениях.
Ограничения на использование серверной объектной модели
Пользовательская логика в надстройках SharePoint всегда распространяется "вниз" на клиент или "вверх" в облако (или "поверх" на некоторые серверы за пределами фермы SharePoint). Во всех этих моделях распространения необходимо использовать одну из клиентских объектных моделей либо конечные точки REST или OData. (Серверную объектную модель нельзя использовать в надстройке SharePoint.) Например, если приложение содержит страницы, размещенные в SharePoint, эти страницы могут получать доступ к данным SharePoint с помощью клиентской объектной модели JavaScript. Такие страницы также могут предоставлять приложения Silverlight, использующие клиентская объектная модель SharePoint Silverlight. Дополнительные сведения о надстройках SharePoint см. в статье Важные аспекты архитектуры надстроек SharePoint и ландшафта разработки.
Клиентские объектные модели для управляемого кода
В SharePoint используются три клиентские объектные модели для управляемого кода: Silverlight, .NET и модель для мобильных устройств.
Клиентская объектная модель .NET
Объектная модель SharePoint для .NET Framework используется в приложениях .NET Framework, которые работают с клиентом Windows, отличном от телефона. Таким клиентом можно считать любое из следующих устройств:
- компьютер пользователя;
- сервер, не входящий в ферму SharePoint;
- веб-роль или рабочая роль в Microsoft Azure;
Практически каждому классу на основном сайте и в объектной модели сервера списков соответствует класс в клиентской объектной модели .NET Framework. Кроме того, клиентская объектная модель .NET Framework предоставляет полный набор API для расширения других компонентов, включая некоторые функции SharePoint, например ECM, таксономию, профили пользователей, расширенный поиск, аналитика, службы BCS и другие.
Для повышения производительности строки кода, написанные в платформа .NET Framework клиентской объектной модели, отправляются на сервер SharePoint пакетами, где они преобразуются в код на стороне сервера и выполняются. Затем запрашиваемые результаты и новое состояние всех переменных возвращаются клиенту. Вы как разработчик определяете, выполняется ли пакет синхронно или асинхронно. (В синхронном пакете приложение платформа .NET Framework ожидает возвращенных результатов с сервера, прежде чем продолжить. В асинхронном пакете обработка на стороне клиента немедленно продолжается, а пользовательский интерфейс клиента остается адаптивным.)
Чтобы запрашивать любой объект IEnumerable, в том числе объекты SharePoint, которые реализуют IEnumerable, вы можете использовать синтаксис запросов LINQ в клиентском коде. Однако при этом используется LINQ to Objects, а не поставщик LINQ to SharePoint, поэтому документация последнего не относится к клиентскому коду.
Сборки для клиентской объектной модели .NET Framework должны устанавливаться в клиенте. Они включены в пакет распространяемого пакета, который можно получить в клиентских компонентах SharePoint.
Примеры использования объектной модели платформа .NET Framework см. в статье Выполнение базовых операций с помощью кода клиентской библиотеки SharePoint.
Примечание.
Вы также можете использовать конечные точки REST или OData SharePoint в приложении на базе .NET Framework. Сравнение клиентской объектной модели платформа .NET Framework с конечными точками REST/OData SharePoint см. в разделе Конечные точки REST/OData далее в этой статье.
Клиентская объектная модель Silverlight
Объектная модель SharePoint для Silverlight используется в приложениях Silverlight независимо от места сохранения компилированного XAP-файла. Это может быть библиотека на веб-сайте SharePoint, на клиентском компьютере, в облачном хранилище или на внешнем сервере. Как правило, приложение Silverlight отображается в SharePoint в объекте SilverlightWebPart . Клиентская объектная модель Silverlight в SharePoint практически идентична клиентской объектной модели .NET Framework и предусматривает поддержку тех же областей расширений. Главное отличие состоит в том, что в версии Silverlight все пакеты команд отправляются на сервер асинхронно, чтобы элементы пользовательского интерфейса приложения оставались активны.
Сборки для клиентской объектной модели Silverlight сохраняются на каждом сервере SharePoint по адресу %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin. Их не нужно устанавливать на компьютер, на котором установлено приложение Silverlight, хотя это предусмотрено. Кроме того, вы их можете сохранить в XAP-файл приложения.
XAP-файлы Silverlight можно включить в надстройки SharePoint, включая приложения, размещенные в SharePoint. В последнем случае выполняется развертывание XAP-файла в библиотеке на сайте приложения. (Дополнительные сведения о веб-приложениях см. в статье Размещение веб-сайтов, веб-приложений надстроек и компонентов SharePoint в SharePoint.) Это делает приложение Silverlight полезным способом включения пользовательского кода SharePoint в приложение, так как пользовательский серверный код не разрешен в надстройках SharePoint. Это также позволяет разработчикам Silverlight использовать имеющиеся навыки для создания приложений SharePoint с минимальной кривой обучения.
Примечание.
Вы также можете использовать конечные точки REST или OData SharePoint в приложении на базе Silverlight. Сравнение клиентской объектной модели Silverlight с конечными точками REST/OData SharePoint см. в разделе Конечные точки REST/OData далее в этой статье.
Объектная модель для мобильных устройств
Для Windows Phone устройств доступна специальная версия клиентской объектной модели Silverlight. Он включает в себя некоторые дополнительные API, относящиеся только к телефонам, например API, которые позволяют телефонным приложениям регистрироваться для получения уведомлений из службы push-уведомлений Майкрософт. Он поддерживает все основные функции SharePoint; однако он не поддерживает ни одну из неядерных областей расширяемости, поддерживаемых двумя другими клиентскими объектными моделями для управляемого кода. Чтобы получить доступ к этим дополнительным областям, используйте конечные точки REST/OData SharePoint в мобильном приложении. См. раздел Конечные точки REST/OData далее в этой статье.
Сборки для мобильной объектной модели сохраняются на каждом сервере SharePoint по адресу %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin. Их необходимо поместить в XAP-файл приложения для Windows Phone.
Объектная модель JavaScript
SharePoint предоставляет объектную модель JavaScript для использования во встроенных сценариях или отдельных JS-файлах. Эта модель включает в себя те же функции, которые предоставляют клиентские объектные модели платформы .NET Framework и Silverlight. Как и клиентская объектная модель Silverlight, объектная модель JavaScript является полезным способом включения пользовательского кода SharePoint в приложение, так как пользовательский серверный код не разрешен в надстройках SharePoint. Она также позволяет веб-разработчикам использовать имеющиеся навыки JavaScript для создания приложений SharePoint с минимальной кривой обучения.
Как и клиентские объектные модели для управляемого кода, инфраструктура JavaScript для SharePoint взаимодействует с серверами фермы с помощью пакетов с кодом, который всегда выполняется асинхронно. Кроме того, сейчас возможно получать доступ к данным SharePoint на разных доменах с помощью JavaScript (но только к данным одного и того же родительского семейства веб-сайтов), что было недопустимо в предыдущих версиях SharePoint. Дополнительные сведения см. Дополнительные сведения см. в статье Обращение к данным SharePoint из надстроек с помощью междоменной библиотеки. Данные возвращаются с сервера с помощью Нотация объектов JavaScript (JSON).
Объектная модель JavaScript определена в наборе *.js файлов, расположенных в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS на каждом сервере.
Примеры использования объектной модели платформа .NET Framework см. в статье Завершение базовых операций с помощью кода библиотеки JavaScript в SharePoint.
Примечание.
Вы также можете использовать конечные точки REST или OData SharePoint в приложении на базе JavaScript. Сравнение клиентской объектной модели JavaScript с конечными точками REST/OData SharePoint см. в следующем разделе Конечные точки REST/OData.
Конечные точки REST и OData
Для сценариев, в которых требуется доступ к сущностям SharePoint из клиентских технологий, которые не используют JavaScript и не основаны на платформах платформа .NET Framework или Silverlight, SharePoint предоставляет реализацию веб-службы rest, которая использует протокол OData для выполнения операций CRUD с данными списка SharePoint. Кроме того, почти каждый интерфейс API клиентской объектной модели имеет соответствующую конечную точку REST. Это позволяет коду напрямую взаимодействовать с артефактами SharePoint с помощью любой технологии, поддерживающей стандартные HTTP-запросы и отклики. Чтобы использовать возможности REST, встроенные в SharePoint, код создает запрос RESTful HTTP для конечной точки, соответствующей необходимому интерфейсу API клиентской объектной модели. Веб-служба client.svc обрабатывает HTTP-запрос и направляет отклик в формате Atom или JSON.
Дополнительные сведения об использовании веб-службы REST/OData см. в разделе Использование операций запросов OData в запросах REST SharePoint. Примеры см. в разделе Завершение базовых операций с помощью конечных точек REST SharePoint.
Сравнение программирования с помощью REST или OData с программированием с помощью клиентской объектной модели
В некоторых ситуациях предпочтительнее использовать конечные точки REST даже в приложениях, для которых доступна объектная модель SharePoint, особенно для разработчиков, у которых нет опыта разработки в Windows. В следующей таблице представлено сравнение основных возможностей этих вариантов программирования для разработчика, создающего приложение на платформе Windows или платформы, поддерживающей JavaScript.
| Компонент | Объектная модель .NET Framework или Silverlight | Объектная модель JavaScript | Конечные точки REST или OData, вызываемые с помощью платформы Windows или JavaScript |
|---|---|---|---|
| Объектно-ориентированное программирование | Да | Да | Нет |
| Пакетная обработка | Да | Да | Да |
| Интерфейсы API для условной обработки и обработки исключений | Да | Нет | Нет |
| Доступность синтаксиса LINQ | Да | Нет | Нет |
| Объединение данных списков из различных веб-приложений SharePoint | Да | Нет | Да |
| Знание разработчиками, использующим REST или OData | Нет | Нет | Да |
| Сходство с программированием не для Windows или с помощью JavaScript | Нет | Да | Да |
| Строгая типизация полей элементов списка | Нет (если не использовать LINQ) | Нет | Да (в случае платформы Windows); нет (в случае JavaScript) |
| Использование jQuery, Knockout и других библиотек JavaScript | Нет | Да | Нет (в случае платформы Windows); да (в случае JavaScript) |
Платформа WCF Data Services
Если вы предпочитаете использовать синтаксис LINQ в клиентских приложениях платформа .NET Framework или Silverlight, SharePoint поддерживает WCF Data Services в качестве поставщика LINQ. Вы можете выбрать listdata.svc (только для данных списка), как в предыдущих версиях SharePoint Foundation, или нацелиться на тот же клиент.svc, который поддерживает интерфейс OData для доступа ко всем сущностям SharePoint в дополнение к данным списка. Дополнительные сведения см. в статье Query SharePoint Foundation with ADO.NET Data Services.
На рисунке 2 показаны отношения между различными клиентскими интерфейсами API, клиентскими приложениями и SharePoint. URL-адреса _api — URL-адреса конечных точек REST, связанные с фермой. Дополнительные сведения см. в статье Дополнительные сведения о службе REST в SharePoint 15.
Рис. 2. Клиентские приложения и интерфейсы API в SharePoint
Нерекомендуемые наборы интерфейсов API
Два набора API по-прежнему поддерживаются в платформе SharePoint для обратной совместимости, но мы не рекомендуем использовать их для новых проектов: веб-служб ASP.NET (asmx) и прямых вызовов удаленных процедур (RPC) в файл owssvr.dll .
См. также
- Обзор разработки решений с помощью SharePoint
- Модели программирования в SharePoint
- Сравнение надстроек SharePoint с решениями SharePoint
- Программирование с использованием службы SharePoint REST
- Выполнение базовых операций с использованием конечных точек SharePoint REST
- Выполнение базовых операций с использованием кода библиотеки клиента в SharePoint
- Выполнение базовых операций с использованием кода библиотеки JavaScript в SharePoint
- API управления жизненным циклом приложений (ALM)
- Запрос SharePoint Foundation с помощью служб данных ADO.NET