SharePoint アドインの設計オプションについて検討する 3 つの方法Three ways to think about design options for SharePoint Add-ins

前提条件: 最初に記事「SharePoint アドイン」をよく読んでください。Prerequisite: You should first be familiar with the article SharePoint Add-ins.

この記事では、3 とおりの方法で SharePoint アドインのアーキテクチャの選択肢について考えます。This article looks at the architectural choices for SharePoint Add-ins in three different ways. 最初に、設計の選択肢の最も重要なカテゴリについて説明します。2 つ目に、アプリケーションの階層という観点でアドインのアーキテクチャを確認します。3 つ目に、設計上の決定をする際に考慮する必要がある一連の要素を示します。First, you learn about the most important categories of design choices; second, you view add-in architecture in terms of application tiers; and, third, you see a set of factors you need to consider when making your design choices.

SharePoint 拡張を、SharePoint アドイン、従来の SharePoint ファーム ソリューション、またはセキュリティで保護されたソリューションのいずれにするかを最初に決定します。The first decision to make is whether your SharePoint extension should be a SharePoint Add-in or a classic SharePoint farm solution or sandboxed solution. SharePoint オブジェクト モデルの一部、特に SharePoint の管理およびセキュリティのカスタマイズと関連するモデルは、クライアントからアクセスできません。Some parts of the SharePoint object model, mainly connected with customizing SharePoint administration and security, are not accessible from clients. それらには、SharePoint サーバー上で実行されるカスタム コードからのみアクセスできますが、SharePoint アドインではカスタム サーバー側コードは許可されません。Only custom code running on the SharePoint server can access them, and custom server-side code is not allowed in a SharePoint Add-in. (豊富なクライアント オブジェクト モデルと REST/OData サービスを使用することで、SharePoint アドインでほとんどのエンドユーザー向け SharePoint 拡張を行うことができます)。(A rich set of client object models and a REST/OData service make it possible for SharePoint Add-ins to do almost any end-user-oriented SharePoint extension.)

従来のソリューションとアドインのいずれにするかを決定する方法の詳細については、「SharePoint アドインと SharePoint ソリューションの比較」を参照してください。For more information about deciding between classic solutions and add-ins, see SharePoint Add-ins compared with SharePoint solutions. また、「SharePoint で適切な API セットを選択する」もこの決定に役立ちます。Also helpful for making this decision is Choose the right API set in SharePoint.

SharePoint アドインの設計における重要な要素Key elements in the design of SharePoint Add-ins

選択肢の 3 つの主要なカテゴリが、SharePoint アドインを設計するときに必要になります。Three major categories of choices need to be made when a SharePoint Add-in is designed. 通常、アプリケーションの設計にはトレードオフが伴います。あるカテゴリでの選択によって、別のカテゴリでの選択肢が制限される場合があります。As always, application design involves trade-offs; choices you make in one category may limit your options in another. 考えられる選択肢の組み合わせすべてが実現可能なわけではありません。Not every possible combination of choices is feasible.

  • ホスティング: SharePoint アドインは、通常、展開方法とホスティング方法に基づいて 2 つの主要なタイプに分けることができます。Hosting: SharePoint Add-ins can be divided into two major types based on how they are deployed and hosted.

    • プロバイダー ホスト型アドインでは、開発者が提供するサーバーまたはクラウド アカウント上の SharePoint の外部で、基本的なデータ ストレージとビジネス ロジックが開発者によって展開およびホストされています。Provider-hosted add-ins have their primary data storage and business logic deployed and hosted by you—the developer—outside of SharePoint in servers or a cloud account that you provide. アドインを購入する異なる顧客のアカウント間で分離する責任は、開発者が負います。You are responsible for enforcing isolation between the accounts of the various customers who purchase your add-in. このようなアドインには、SharePoint コンポーネントを含めることもできます。Such add-ins can have SharePoint components too. これらは、顧客の SharePoint ファームでホストされています。These are hosted in the customer's SharePoint farm. このタイプのアドインでは、設計の選択肢の他のカテゴリにおいて最も高い柔軟性が確保されます。This type of add-in provides you with the most flexibility in the other categories of design choices. また、外部のデータ、ロジック、および Web ユーザー インターフェイス (UI) に Microsoft 以外のプラットフォームを使用することもできます。It also enables you to use non-Microsoft platforms for the external data, logic, and web user interface (UI). (プロバイダー ホスト型アドインのカテゴリ内では、リモート コンポーネントが SharePoint ファームと同じ会社のファイアウォール内にあるアドインと、リモート コンポーネントがそのファイアウォールの外にあるアドインを区別する必要もあります。(Within the category of provider-hosted add-ins, you also need to distinguish between add-ins whose remote components are within the same corporate firewall as the SharePoint farm and those whose remote components are outside of that firewall. これら 2 つのシナリオでは承認システムが異なります。そのため、SharePoint データへのアクセスに使用するプログラミング言語も異なります)。The authorization systems for these two scenarios are different, which, in turn, makes a difference in which programming language you use to access the SharePoint data.)

    • SharePoint ホスト型アドインは、リスト、コンテンツ タイプ、ワークフロー、Web パーツなど、すべて SharePoint コンポーネントで構成されます。外部コンポーネントは含まれません。SharePoint アドインに含めることができる SharePoint コンポーネントの種類の詳細については、「SharePoint のホスト Web、アドイン Web、および SharePoint コンポーネント」を参照してください。SharePoint-hosted add-ins consist entirely of SharePoint components, such as lists, content types, workflows, and Web Parts. There are no external components. For more information about the kinds of SharePoint components that can be included in SharePoint Add-ins, see Host webs, add-in webs, and SharePoint components in SharePoint.

    SharePoint アドインのホスティング オプションの詳細については、「SharePoint アドインを開発およびホストするためのパターンを選択する」を参照してください。For more detailed information about the hosting options of SharePoint Add-ins, see Choose patterns for developing and hosting your SharePoint Add-in.

  • 接続性: SharePoint は、3 種類のセキュリティで保護されたデータに対する作成/読み取り/更新/削除 (CRUD) アクセスをサポートします。Connectivity: SharePoint supports three kinds of secure create/read/update/delete (CRUD) access to data.

    SharePoint アドインでのデータの格納とアクセスの詳細については、「SharePoint アドインのデータ ストレージ」、「SharePoint アドインのセキュリティで保護されたデータ アクセスとクライアント オブジェクト モデル」、および「SharePoint の外部データの操作」を参照してください。For more information about data storage and access in SharePoint Add-ins, see Data storage in SharePoint Add-ins, Secure data access and client object models for SharePoint Add-ins, and Work with external data in SharePoint.

  • UI: SharePoint で SharePoint アドインを表示する方法は 3 通りあります。少なくとも、すべてのアドインが完全な Web ページで表示されます。オプションで、アドイン パーツを使用して、またメニュー アイテムやリボンのボタンを使用してアドインを表示することもできます。詳細については、「SharePoint アドインの UX 設計」を参照してください。UI: There are three ways to surface a SharePoint Add-in in SharePoint: at a minimum, all add-ins are surfaced in a full web page. Optionally, an add-in can also be surfaced through an add-in part, and through a menu item or ribbon button. For more information, see UX design for SharePoint Add-ins.


SharePoint アドインは、顧客によって、テナント内の複数のサイト コレクションにインストールされたり、Web サイト単位でインストールされたりします。SharePoint Add-ins can be installed by your customers to multiple site collections in a tenancy, or on a website-by-website basis. 前者はテナントをスコープにしたアドインと呼ばれます。テナントをスコープにした選択肢を顧客に提供する場合は、カスタムのリボンのボタンやアドイン パーツを含めることはできません。The former are called tenant-scoped add-ins. If you want your customers to have the tenant-scoped option, you may not include a custom ribbon button or an add-in part. 詳細については、「SharePoint アドインのテナントと展開スコープ」を参照してください。For more information, see Tenancies and deployment scopes for SharePoint Add-ins.

アーキテクチャ階層Architectural tiers

アドインのアーキテクチャの選択肢に関する別の考え方では、アドインに UI、ビジネス ロジック、データ アクセスの 3 つの論理階層があると考えます。各レイヤーには、複数の実装の選択肢があります。ここでも、あるレイヤーでの選択によって、別のレイヤーでの選択肢が制限されます。以下の表では、アドインのリモート コンポーネントと SharePoint コンポーネントについて、選択肢の一部とその用途を説明しています。Another way to think about your add-in architecture options is to think of the add-in as having three logical tiers: the UI, the business logic, and the data access. Each layer has multiple implementation options; again, choices made for one layer limit the options for others. The following tables describe some of the options, and their uses, for the remote components of an add-in and the SharePoint components.

プロバイダー ホスト型アドインのリモート コンポーネント: 階層ごとのオプションRemote components in provider-hosted add-ins: options for each tier

階層Tier オプションOptions 適用Good for
UIUI ASP.NET 形式の ASP.NET ページまたは Azure Web ロールでホストされている MVC アプリケーション。ASP.NET pages in an ASP.NET form or MVC application that is hosted in an Azure web role ASP.NET 開発スタッフのスキルの活用Leveraging the skills of an ASP.NET development staff
JavaScript を使用した HTML 5 ページHTML 5 page with JavaScript リッチなユーザー インターフェイスRich user interface
Microsoft 以外のクラウド サービスでホストされている PHP またはその他の種類の Web ページPHP or other kind of web page hosted in a non-Microsoft cloud service Microsoft 以外のアプリケーションの SharePoint への統合Integrating non-Microsoft applications into SharePoint
Windows Phone アプリでの SilverlightSilverlight in a Windows Phone app SharePoint データへのモバイル アクセスと、位置情報データおよびプッシュ通知との統合Mobile access to SharePoint data and integration with geolocation data and push notifications
ビジネス ロジックBusiness logic クライアント側の JavaScriptClient-side JavaScript UI ロジックと単純なビジネス ロジック。JavaScript クライアント オブジェクト モデル経由の SharePoint データへのアクセスUI logic and light business logic; accessing SharePoint data through the JavaScript client object model
Microsoft Azure ワーカー ロールA Microsoft Azure worker role プロセッサ負荷の高い機能。.NET Framework クライアント オブジェクト モデルを通じた SharePoint データへのアクセスProcessor-intensive functionality; accessing SharePoint data through the .NET Framework client object model
リモート Web サービスA remote web service プロセッサ負荷の高い機能。.NET Framework クライアント オブジェクト モデルを通じた SharePoint データへのアクセスProcessor-intensive functionality; accessing SharePoint data through the .NET Framework client object model
データData SQL AzureSQL Azure フル機能のリレーショナル データFull-featured relational data
Azure のテーブル ストレージAzure Table storage アプリケーションの設定およびその他のメタデータApplication settings and other metadata
Azure BLOB ストレージAzure Blob storage 大きなファイルのストレージStorage of large files
Microsoft 以外のクラウド サービスA non-Microsoft cloud service Microsoft 以外のプラットフォームを基盤とする既存のデータ ソースの活用Leveraging existing data sources that are based on non-Microsoft platforms
開発者の独自のサーバー上のデータベースA database on the developer's own server テナント分離のプロバイダー ホスティングと開発者制御Provider-hosting and developer control of tenancy isolation

SharePoint コンポーネント: 階層ごとのオプションSharePoint components: options for each tier

階層Tier オプションOptions 適用Good for
UIUI アドイン Web ページ上の SharePoint のリストとライブラリのカスタム ビューCustom views of SharePoint lists and libraries on add-in web pages SharePoint の外観と動作との最大限の統合Maximizing integration with SharePoint appearance and behavior
アドイン Web ページ上の Web パーツ (または タグ) 内でホストされる Silverlight アプリケーションSilverlight application hosted in a Web Part (or within tags) on an add-in web page 既存の Silverlight 開発経験の活用。豊富なユーザー インターフェイスLeveraging existing Silverlight development experience; rich user interface
ビジネス ロジックBusiness logic SharePoint ワークフローA SharePoint workflow ビジネス プロセスの実装Implementing business processes
SharePoint クロスドメイン ライブラリで補足されるクライアント側の JavaScriptClient-side JavaScript supplemented with the SharePoint cross-domain library アドイン Web 内の SharePoint データへのアクセス。テナント内の他の Web サイトのデータへのアクセスAccessing SharePoint data in the add-in web; accessing data in other websites within the tenancy
リモート イベント ハンドラーA remote event handler 外部でホストされるロジックを使用した SharePoint リストおよびライブラリの CRUD イベントの処理Handling CRUD events in SharePoint lists and libraries using externally hosted logic
データData Collaborative Application Markup Language (CAML)、LINQ、またはいずれかの SharePoint クライアント オブジェクト モデルを使用したクエリによって照会される SharePoint のリストおよびライブラリSharePoint lists and libraries that are queried through Collaborative Application Markup Language (CAML), or LINQ queries with one of the SharePoint client object models 既存の SharePoint および .NET Framework 開発経験の活用。Leveraging existing SharePoint and .NET Framework development experience
SharePoint REST/OData Web サービスを通じて照会する SharePoint リストおよびライブラリSharePoint lists and libraries that are queried through the SharePoint REST/OData web service Microsoft 以外のプラットフォームからの SharePoint データへのアクセス。既存の OData クエリ経験の活用Accessing SharePoint data from non-Microsoft platforms; leveraging existing OData query experience
BCS モデルA BCS Model SharePoint で外部データを SharePoint リストとして表示Surfacing external data in SharePoint as a SharePoint list

設計決定時に考慮すべき要素Factors to consider when making your design decisions

SharePoint アドイン モデルでは、単純なデシジョン ツリーで対処できないほど多くの設計上の可能性が提供されます。以下に、SharePoint アドインのアーキテクチャを構築する際に考慮すべき最も重要な要素の一部を示します。The SharePoint Add-in model enables so many possibilities for design that a simple decision tree is not possible. The following are some of the most important factors to consider when constructing the architecture of a SharePoint Add-in.

  • 当然ながら、最も重要なのは、顧客が使用できる機能 (ユース ケース) にすることです。Most importantly, of course, is the functionality you want to make available to customers—the use cases. たとえば、ビデオ ファイルを別のビデオ フォーマットに変換するなどの、プロセッサ集約的な機能をアドインに含める場合、そのことが、処理が開発者のサーバーのいずれかまたは Azure ワーカー ロールで実行される、プロバイダー ホスト型アドインを作成する根拠となります。For example, if your add-in includes processor-intensive functions, such as converting video files to another video format, that would be an argument for creating a provider-hosted add-in in which the processing is done on one of your servers or an Azure worker role.

  • SharePoint アドインの 1 つの種類であるプロバイダー ホスト型アドインでは、開発者 (または顧客) が SharePoint 以外のコンポーネントをホストし、テナントの分割を実施する必要があるため、これを実行するハードウェアおよび IT スタッフを用意するかどうか (または、対象の顧客がこれを実行するかどうか) を検討しなければなりません。Because one kind of SharePoint Add-in, provider-hosted add-ins, requires you (or your customer) to host the non-SharePoint components and to enforce tenant isolation, you need to consider whether you have the hardware and IT staff to do this (or whether your targeted customers do).

  • どのような顧客を対象とするかも非常に重要な考慮事項です。アドインが社内で使用される (つまり、外部のユーザーがいない)、または単一の顧客によって使用される場合、プロバイダー ホスト型アドインの実装と管理は、外部の顧客がいる、または複数の顧客がアドインを使用する場合に比べ大幅に容易になります。アドインを一般に販売する予定である場合は、SharePoint Online アカウントを持つ企業または独自の SharePoint ファームを持つ企業、もしくはその両方のいずれを販売対象とするのかも検討する必要があります。Which customers you are targeting is also a crucial consideration. If all your add-ins will be used in-house (that is, you have no external customers) or used by a single customer, provider-hosted add-ins are significantly easier to implement and maintain than when you have external customers or multiple customers will use the add-in. If you intend to sell the add-in publicly, you should also consider whether you will market it to businesses that have SharePoint Online accounts or those with their own SharePoint farms, or both.

  • 自分自身または開発スタッフの現在のスキルについても考慮する必要があります。たとえば、自分が経験豊富な ASP.NET 開発者である場合、そのことが、リモート Web アプリケーションを作成し、ASP.NET ページ上に SharePoint リスト データを表示するという方法を選択するポイントとなります。対照的に、自分が経験豊富な SharePoint 開発者である場合、そのことが、カスタムの SharePoint リストおよびサイト ページを使用し、JavaScript で処理を実行するという方法を選択するポイントとなります。You should also consider your existing skills or the skills of your development staff. For example, if you are an experienced ASP.NET developer, that would be a point in favor of creating a remote web application and surfacing SharePoint list data on an ASP.NET page. On the other hand, if you are an experienced SharePoint developer, that would be a point in favor of using a custom SharePoint list and site page, with JavaScript to perform processing.

関連項目See also