アーキテクチャ概念について

学習の目的

この単元を完了すると、次のことができるようになります。
  • Visualforce ページパラダイムと Aura コンポーネントパラダイムの違いを説明する。
  • さまざまなコンテナの概念とコンテナに Aura アプリケーションまたはコンポーネントを挿入する方法を説明する。

概念: 複数ページアプリケーションと単一ページアプリケーション

従来の Visualforce ベースのアプリケーションを設計する場合、通常は一連のページを作成し、アプリケーションのユーザは、1 つのページから別のページに移動することでナビゲーションを行います。[リスト] 表示ページから開始して、[表示] リンクをクリックしてレコード表示ページに移動し、[編集] ボタンをクリックしてレコード編集ページに移動する、などです。

Aura コンポーネントのアプリケーションは大きく異なります。アプリケーション全体で 1 つの「ページ」しかありません。これは「単一ページアプリケーション」 (SPA) と呼ばれます。SPA は、単一のページと多くの JavaScript を読み込みます。読み込まれた後は、JavaScript によって「ページ」のユーザインターフェースが実行されて更新されます。

ユーザは、ページからページへ遷移するのではなく、状態から状態へと遷移します。状態は、アプリケーションの現在のモードを表します。リストビュー状態、レコード表示状態などです。

SPA は各状態にどのコンポーネントを読み込むかを知っており、それらのコンポーネントはどのように自身を表示するのかを知っています。

要点は次の 2 つです。1 つ目は、Aura コンポーネントではナビゲーションが大きく異なるということです。アプリケーションの複雑度と実行する場所によっては、ナビゲーションについて心配する必要がまったくない場合もあります。PageReference や $Action、そして、手動で作成する URL のアンチパターンには別れを告げましょう。(あの悪夢!)

ただし、新しい技法をいくつか学習する必要があるでしょう。詳細は「リソース」セクションを参照してください。

2 つ目は、新しい概念に分けて説明しましょう。

概念: ページとコンポーネント

Visualforce ページと Aura コンポーネントがどのように Salesforce に保存されているのかは前述しました。細かい違いはありますが、現状のレベルではまだ両者はほぼ同じです。どちらもコードの塊であり、ページという塊またはコンポーネントという塊は基本的なビルディングブロックです。

ただし、この 2 種類のブロックを使用してどのように構築するのかは大きく異なります (この流れは予想できたと思います)。

メモ

メモ

Visualforce コンポーネントについては、ここでは考慮しません。次のセクションで説明します。

単純に言うと、Visualforce ページは「大きな」ビルディングブロックです。ページレイアウトに「ウィジェット」として含めたり、<apex:include> タグを使用して 1 つのページを別のページに含めたりすることはできますが、これができるのは一握りのページだけです。「小さな」ページの集合をまとめて「中程度の」ページを作成し、それらをいくつか組み合わせて「大きな」ページを作成することはできません。Visualforce はそのようには設計されておらず、それを実行しようとすると、問題のある動作が発生します。

Aura コンポーネントは違います。「大きな」 Aura コンポーネントは、数十あるいは数百もの小さなコンポーネントで構成でき、それらのコンポーネント自体も、さらに小さなコンポーネントで構成できます。Aura プログラミングモデルは、1 つのアプリケーションを構成する何千ものコンポーネントを処理するように設計されています。

小さく細分化されたコンポーネントを使用して「1 つ上のレベル」のコンポーネントを作成するということを何度も繰り返すのが、Aura コンポーネントを使用した基本的な設計プロセスです。ソフトウェア設計では、これはコンポジションと呼ばれます。「コンポーネント」と「コンポジション」という言葉は明らかに似ていますね (語源であるラテン語の「コン」「一緒に」「共に」を意味します)。これは偶然ではありません。

Visualforce ページは概してスタンドアロンとして使用されます。そのため (他の理由もありますが)、一意のパラメータ URL を使用して Visualforce ページにアクセスできます。

一方、Aura コンポーネントは大きな全体を構成する一部であり、それはコンポーネントがいくら「大き」くても同じです。特定の URL で個々のコンポーネントにアクセスすることはできません。コンポーネントを実行するには、「Aura コンポーネントのスキルとツール」モジュールで行ったように、コンポーネントをさらに大きい何かに追加する必要があります

これについて語りきることはできません。ソフトウェア設計におけるコンポーネントの使用に関しては、何冊もの本が書かれているほどです。ここでは、コンポーネントをページのように扱ってはいけないということだけを覚えておいてください。

概念: コンポーネントとコンポーネント

前のセクションでは、Visualforce コンポーネントについては触れませんでした。それでは説明に偏りが出てしまいますね。つまるところ、Visualforce フレームワークに組み込まれた多くの「タグ」は、それぞれ名前の異なるコンポーネントなのですから。当然 Visualforce にはコンポーネントがあり、Visualforce ページでは何百もの組み込み「タグ」が使用できます。そのため Aura コンポーネントと非常に似ているように思えます。違いはなんだろう?

単純に言うと、新しい Visualforce コンポーネント (タグ) を Salesforce の開発者が作成するときは、カスタム Visualforce コンポーネントをお客様が開発するときよりも多くの機能にアクセスできます。その機能の多くが、お客様向けの Aura コンポーネントには取り入れられています。カスタム Visualforce コンポーネントは、カスタム Aura コンポーネントほど強力ではなく、機能も限られています。

ただし、声を大にして言いたいのは、多くのお客様が効果的にカスタム Visualforce コンポーネントを作成しているということです。カスタム Visualforce コンポーネントは優れた機能であり、それを使用するのは素晴らしいことです。カスタム Visualforce コンポーネントを使用していることは、洗練された開発の証であり、多くの場合、長期的なソフトウェア開発コストの削減につながります。Visualforce カスタムコンポーネントが良くないということはありません。

ただし両者を比較すると、Aura コンポーネントの方が優れています。いっそう洗練、強化されています。適切に使用すれば、時間の経過と共に、機能の充実した、優れたソフトウェアを同等のコストで作成できます。

大きな違いをいくつか具体的に見ていきましょう。

  • Aura コンポーネントは、イベントを起動したり受信したりして、コンポーネント間で通信します。フレームワークイベントまたはコンテナイベントを使用するか、独自のイベントを定義できます。イベントハンドラを記述すると、適切なイベントが発生したときに、フレームワークによって詳細が処理されます。これは大きな利点であり、アプリケーション設計の可能性が大きく広がります。同様のものは Visualforce にはなく、自分で創り出すしかありません。それができたなら、独自のフレームワークが完成したことになります! 他に必要なものは、ひねりがきいた名前と GitHub リポジトリとヒップスターらしい帽子だけです。
  • Aura コンポーネントバンドルの構造では、異なる機能は異なるアイテムを持ち、それらが自動的に結び付けられます。異なる要素を別個に保ってコンポーネントの重要な連動関係をグループ化できることは、組織化の優れたツールとなります。値プロバイダなどによって、最小限の準備でさまざまな要素を簡単に使用できます。先ほどと同様、同等のものを Visualforce で実現するには、機能コードではなくフレームワークコードを記述する必要があります。
  • Aura コンポーネントは、多くのコンテキストで使用できます。クライアント側のコードであるため、Lightning Out を使用して「Salesforce」機能をまったく Salesforce とは関係のないアプリケーションやコンテキスト、たとえば SharePoint などに取り込むことができます。Visualforce はサーバにバインドされているため、Salesforce 上でのみ実行されます。

他にもまだまだ違いはありますが、次の概念に移りましょう。このモジュールの終わりまでには、Aura コンポーネントの導入を真剣に検討しなければならない理由が、おわかりいただけるかと思います。

概念: アプリケーションコンテナ

アプリケーションコンテナ (短縮してコンテナ) は、ほとんどの Salesforce 開発者にとって新しい概念です。端的に言うと、コンテナとはアプリケーションのコンテキスト、つまりコードが実行される環境です。Aura コンポーネントの最も代表的なコンテナは Lightning Experience です。Lightning Experience と Salesforce アプリケーションには多くの共通コードが含まれており、それらには同じ URL でアクセスするため、両者を合わせて「one.app コンテナ」と呼ぶ場合もあります。(両方の共通 URL の末尾が one.app であるためです。)

メモ

メモ

Lightning Experience と Salesforce アプリケーションには重要な違いがあります。Salesforce アプリケーションは一般に Web ブラウザではなく、モバイルデバイスのネイティブアプリケーションからアクセスされます。ここではその点について議論しませんが、留意しておいてください。

その他のコンテナとして、Salesforce Classic コンテナなら、思いついた方もいらっしゃるでしょう。コードが実行される可能性のあるコンテナのリストを次に示します (すべてを網羅したリストであるとは限りません)。

  • Salesforce Classic
  • Visualforce
  • Salesforce アプリケーション
  • Lightning Experience
  • Lightning アプリケーションビルダー (LAB)
  • Lightning コンソールアプリケーション
  • コミュニティ
  • Visualforce の Lightning コンポーネント (LC4VF)
  • Lightning Out
  • Lightning for Outlook および Lightning for Gmail
  • スタンドアロンの my.app

このリストに目を通した後、次の 2 つのことをお考えになるでしょう。

  1. たくさんコンテナがあるなあ。違いはなんだろう? なぜそれを気にする必要がある? (簡単な答え: コンテナサービス)。
  2. ちょっと待てよ。いくつかは、同じものじゃないか。LAB ページは Lightning Experience なのでは? Visualforce が Visualforce 自体のコンテナ? LC4VF との違いは? (簡単な答え: ロシアの人形)。

コンテナサービス

コンテナとはアプリケーションのコンテキスト、つまりコードが実行される環境です。異なる環境では、異なるサービスが提供されます。

たとえば、one.app コンテナ (Lightning Experience と Salesforce アプリケーション) では、レコードに移動する、レコードを作成または編集する、URL を開くといった、イベントの処理がサービスとして提供されます。

他のコンテナではこれらのサービスは提供されません。あるコンテナのサービスに依存するコンポーネントは、そのサービスが提供されない別のコンテナでは機能しません。たとえば、新規レコードの作成に force:createRecord イベントを使用すると、Lightning Experience では適切に機能しますが、そのコンポーネントをスタンドアロンアプリケーションや Lightning Out 内で使用すると、イベントを処理するものがないため、動作が停止します。

「誰もいない森の中で木が倒れたら音はするのか?」という問題は哲学者に任せるとします。

「何もリスンしていないコンテナの中でイベントを起動しても、果たして効果はあるのか?」という問題には答えることができます。答えはノーです。

高度な操作

どのような回避策があるでしょうか? レコードを作成するための独自のコンテナサービスと force:createRecord イベントをキャッチするイベントハンドラを記述し、カスタムサービスにディスパッチします。

手間のかかる作業に思えるのは、実際にそのとおりだからです。堅牢なコンテナサービスを提供することは大変です。エンジニアリングチーム全体がそれに注力しています。この高度なトピックに取り組みつつ、Lightning Experience と Salesforce アプリケーションの他にサービスを使用する必要がある場合は、AppExchange で探してみてください。

ここでは、サービスを網羅したリストを記載し、それらをコンテナに対応付けるスペースはありません。使用したい機能のドキュメントを参照し、次のような免責事項に注意してください。

このイベントは、one.app コンテナによって処理されます。Lightning Experience および Salesforce アプリケーションでのみサポートされています。

コンテナのコンテインメント (または「ロシアの人形」の場合)

コンテナには境界があります。壁、あるいはバリアと言ってもよいでしょう。コンテナは、中のものを閉じ込め、外のものを閉め出します。

これは、アプリケーションコンテナにも当てはまります。Web アプリケーションとフレームワークの境界は、多くの場合 HTML の iframe に基づくものであり、これはブラウザによって適用されます。iframe の内部にあるコードは iframe の外部にある要素に直接アクセスできません。

その他の境界もあります。たとえば、コンテナ自体が内部で起動されたイベントをトラップすることによって、境界を適用できます。

ここからが面白いところです。大きなコンテナの内部に小さなコンテナを配置して、コンテインメント階層に複数の「レイヤ」を作成できます。入れ子になっているロシアの有名なマトリョーシカ人形は、Aura コンポーネントのアプリケーションコンテナをうまく喩えています。コンテナを含むコンテナがまたコンテナに含まれて…

LC4VF を使用して Aura コンポーネント (4) を Visualforce ページ (3) 内で実行できます。そして、その Visualforce ページを Lightning Experience に追加できます。これでコンテナが 3 つになりました。または、LAB を使用して Visualforce ページを Lightning ページ (2) に追加して、さらにその Lightning ページを Lightning Experience (1) に追加できます。これでコンテナは 4 つになりました。さらにコンテインメントレイヤを 5 つ、6 つと増やしていくのは難しいことではありません。

ここが重要な部分です。Aura コンポーネントコードは、それを内部で実行するコンテナのサービスのみにアクセスできます。そのコンテナが別のコンテナの内部にある場合も同じです。

Visualforce ページ内の Aura コンポーネントは、機能する Lightning Experience イベントを起動できないということになります。これは、その Visualforce ページを Lightning Experience に追加したとしても、Visualforce コンテナはイベントを解釈したり、上位のコンテナに渡したりすることができないためです。Visualforce と Lightning Experience との間の iframe の境界によって、それらのイベントがブロックされます。

要するに、コンポーネントは、それが実行されるコンテナのサービスのみを使用できます。複数のコンテキスト用のコンポーネントを作成する場合は、異なるサービスセットに対応するために複数のコードパスが必要です。この手法の例については、「Lightning Components in Visualforce with Lightning Out (Lightning Out を使用した Visualforce 内での Lightning コンポーネント)」を参照してください。