ASP.NET 2.0 の新しいパーソナライゼーション機能

Sean "Early" Campbell
Scott "Adopter" Swigart
3 Leaf Solutions

October 2003
日本語版最終更新日 2003 年 12 月 9 日

概要 : ASP.NET 2.0 の新しいパーソナライゼーション フレームワークを使用して、Web アプリケーションにパーソナライゼーション サポートを簡単に追加する方法について説明します。 最小限のコードを使用して、高度にカスタマイズされたエクスペリエンスをユーザーに提供できるようになります。

目次

はじめに
パーソナライゼーションのセットアップ
Profile オブジェクトの使用
パーソナライゼーション フレームワークの拡張
まとめ

はじめに

現在のほとんどの Web アプリケーションでは、それぞれのユーザー独特の好みやニーズに合わせてカスタマイズされたエクスペリエンスを提供できる何らかの機能が必要になります。 Microsoft® ASP.NET v1.x では、ユーザーの資格情報を検証し、アプリケーション リソースへのアクセスを管理する認証フレームワークが提供されましたが、ユーザー固有のデータを保存および公開するための標準的なメカニズムは提供されませんでした。 Page クラスの User プロパティにはユーザー名や役割メンバシップなど一部の基本的な情報が含まれていますが、ビジネス関連のデータを処理する手段は提供されていません。

コード ネーム ASP.NET 2.0 (後ろに続くコード ネームは次期リリースの Microsoft® Visual Studio® .NET を指します) である次期リリースの Microsoft ASP.NET には、カスタマイズされたアプリケーション エクスペリエンスをユーザーに提供するのに必要なすべてのサービスが組み込まれた、完全なパーソナライゼーション フレームワークが含まれます。 特に、このフレームワークによって公開される API のセットには、データ ストアとの間のパーソナライゼーション データの保存と取得に関わるすべての作業を処理する機能が備わっています。 これらの API は、大抵の Web アプリケーションの要件を処理できるようにデザインされていますが、フレームワークを拡張して、カスタム要件をサポートすることも可能です。 ユーザー情報、ユーザーの選択、およびビジネス情報など、すべての種類のデータを定義および管理できます。 構成情報は web.config に格納され、ユーザー データは、ユーザーが次にアクセスするまで、データ ストアに自動的に保存されます。

ASP.NET 2.0 には、新しい Web アプリケーション管理ツールがあり、このツールによって、パーソナライゼーションの構成を管理するデザイン時インターフェイスが提供されます。 この資料を執筆時点では、このツールはまだ完全に実装されていないので、この資料ではパーソナライゼーションの構成に使用される web.config の基になる XML について調べます。 また、Web ページ内からパーソナライゼーション フレームワークを使って作業する方法と、より複雑なアプリケーション要件をサポートするためにフレームワークを拡張する方法についても説明します。

パーソナライゼーションのセットアップ

パーソナライゼーションは、ASP.NET のインストール時に、すべての Web アプリケーションに対して自動的に有効になります。 machine.config のパーソナライゼーション セクションに移動すると、既定の設定を表示できます。これらの設定をオーバーライドするには、Web アプリケーションの web.config ファイルに <personalization> セクションを追加します。 パーソナライゼーションの構成には 3 つの主要な作業があります。 最初に、パーソナライゼーション フレームワークの一般的な動作を指定する必要があります。 次に、パーソナライゼーション プロバイダを指定することにより、パーソナライゼーション データがどのように保存されるかを特定します。 最後に、パーソナライゼーション フレームワークで管理されるプロファイルまたはユーザー値のセットを定義します。 構成後、パーソナライゼーション API を使用してページのコードを記述できます。

フレームワーク オプションの構成

パーソナライゼーション システムの一般的な操作に影響する、2 つの主要なオプションを設定できます。 1 つは、単にパーソナライゼーション フレームワークを有効および無効にすることです。 次のコードにより、アプリケーションのパーソナライゼーションが有効になります。

<personalization enabled="true" />

パーソナライゼーションを無効にするのは簡単で、有効にした属性を false に設定するだけです。 ただし、これは実行時にチェックされる単なるフラグではありません。 この設定は Web アプリケーションのコンパイル方法に実際に影響します。 この設定が有効になっていると、各 Page オブジェクトにより、パーソナライゼーション システムへのアクセスを提供する Profile プロパティが公開されます。 false に設定されると、Page クラスは Profile プロパティなしでコンパイルされます。 Profile オブジェクトに対してコードを記述した後でパーソナライゼーションを無効にすると、コードはコンパイルされません。 ただし、アプリケーションでパーソナライゼーションが使用しない場合、パーソナライゼーションによってメモリ、CPU、およびディスク入出力にオーバーヘッドが生じるので、パーソナライズを無効にする必要があります。

もう 1 つの管理可能なグローバルな動作は、匿名ユーザーに対するパーソナライゼーションの操作方法です。 パーソナライゼーションは新しいメンバシップ フレームワークとシームレスに動作するようにデザインされています。 ユーザーが認証されるときにユーザー ID が認識され、パーソナライゼーション システムでは、この ID を使用してパーソナライゼーション データを管理できます。 多くの Web サイトでは、認証済みユーザーに対してのみ、パーソナライゼーション データが使用されます。 既定の設定では、匿名ユーザーに対してパーソナライゼーションを無効にすることで、このことが反映されています。 認証されていないユーザーのパーソナライゼーション プロパティにアクセスまたは書き込みをしようとすると、例外が発生します。

パーソナライゼーションで匿名ユーザーをサポートする場合、明示的に匿名ユーザーを有効にする必要があります。 これを行うには、anonymousIdentification 要素を追加します。 書き込み時に、web.config の system.web セクション内に personalization タグではなく、このタグが表示されます。 匿名サポートでは、アプリケーションがユーザー ID またはチケットがクライアントに Cookie として保存する必要があります。 このチケットは、パーソナライゼーション システムが適切なデータを照合できるように、ページにアクセスするたびに提供されます。 anonymousIdentification タグにより、この Cookie の動作を管理するさまざまな属性が提供されます。 次のコードによって匿名 ID が有効になり、最後のページ要求から 100,000 分間が有効期限である暗号化された Cookie が定義されます。

<anonymousIdentification enabled="true" 
cookieName=".ASPXANONYMOUS"
cookieTimeout="100000" 
cookiePath="/" 
cookieRequireSSL="false"
cookieSlidingExpiration="true"
cookieProtection="Encryption"
cookieless="UseDeviceProfile" />

データは、通常は数週間から数か月、時には無期限に保持する必要があるので、パーソナライゼーション Cookie のタイムアウトは一般的にセッション タイムアウトよりもはるかに長くなります。 この Cookie 内の唯一の情報は、システムで生成されたユーザー ID であることに注意してください。 プロファイル データ自体は、認証済みユーザーのデータと完全に同じ形式でパーソナライゼーション データ ストアに格納されます。

プロバイダの構成

パーソナライゼーション フレームワークではプロバイダ モデルを使用して、基になるデータ ストアを管理するのに必要なすべての低レベルのコードをカプセル化します。 パーソナライゼーション プロバイダは基本的にはデータ アクセス オブジェクトで、特にパーソナライゼーション システムでの使用向けにデザインされています。 ASP.NET 2.0 では 2 つのプロバイダが提供されます。この資料の後半では、カスタム プロバイダを作成する方法について説明します。 AccessPersonalizationProvider および SqlPersonalizationProvider のいずれかを選択でき、それぞれのプロバイダにより Microsoft® Access および Microsoft® SQL Server? データベースがカプセル化されます。 Access プロバイダは小規模ビジネス サイトまたは部門レベルのエンタープライズ ソリューション向けにデザインされています。 Access プロバイダを使用することで配置を簡略化できます。 SQL Server プロバイダは、SQL Server ならではの追加のスケーラビリティ オプションが必要な、大規模エンタープライズまたは商用サイト向けにデザインされています。 すべてのプロバイダで同じインターフェイスのセットが実装されるので、どちらのプロバイダを選択してもコードに影響はありません。

アプリケーションに適したプロバイダを選択したら、どのプロバイダを使用するかをパーソナライゼーション フレームワークに通知し、プロバイダが正しく動作するために必要な構成情報を提供します。 Access プロバイダおよび SQL プロバイダには、単に接続文字列が必要になります。 次のコードにより、各プロバイダの 1 つのインスタンスが公開されます。

<personalization 
    enabled="true" 
    defaultProvider="AspNetAccessProvider" >
    <providers>
        <add 
            name="AspNetSqlProvider"     
type="System.Web.Personalization.SqlPersonalizationProvider,
System.Web,
 Version=1.2.3400.0, 
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
            connectionStringName="LocalSqlServer" />
        <add 
            name="AspNetAccessProvider" 
type="System.Web.Personalization.AccessPersonalizationProvider,
 System.Web, Version=1.2.3400.0, Culture=neutral, 
PublicKeyToken=b03f5f7f11d50a3a" 
            connectionStringName="MembershipDataFile"/>
</providers>
</personalization>

単一のアプリケーションに、複数のプロバイダ インスタンスを公開できることがわかります。 これにより、ユーザー データが複数のデータ ストアで管理される場合のある、複雑なシナリオをサポートできます。 たとえば、ユーザーのサイト表示の好みをローカル Access データベースに保存し、ユーザーの請求情報をリモート SQL Server に保存する場合などです。 次のセクションでは、特定の値を管理する場所を指定する方法について説明しますが、ここでは、パーソナライゼーション タグに defaultProvider 属性を指定できることに注目してください。 この属性は、既定でパーソナライゼーション データの管理にどのプロバイダを使用するかを識別します。

プロファイルの定義

ここまでは、パーソナライゼーションの構成とプロバイダの定義の方法について見てきました。次に、ユーザーのプロファイルを構成する値のセットを定義する方法について説明します。 格納するプロファイルの値ごとに <property> エントリを追加する必要があります。 文字列やブール値などの単純なスカラ値、コレクションなどのより複雑な型、さらにユーザー定義型など、実質的にすべての種類のオブジェクトを格納できます。 通常、プロパティ定義は少なくとも名前と型から構成されます。 IDE およびランタイムにより、Microsoft® IntelliSense®、コンパイル、およびランタイムの型チェックなど、厳密に型指定されるサービスを提供できるようになるので、型情報が重要になります。

スカラ型のプロパティ エントリは非常に単純です。 たとえば、ページに表示するユーザーの選択数のフォーラム メッセージを格納する場合、次のコードでプロファイルのプロパティを定義できます。

<profile>
<property name="MessagesPerPage" type="int" />
</profile>

次の表は、プロパティ定義をさらに洗練するために使用できる、その他の省略可能な属性の一覧です。

パーソナライゼーション システムでは、コレクションなど、より複雑な型がサポートされます。 実際に、すべてのシリアル化可能なオブジェクトを格納できます。 型の属性に完全修飾の型参照が必要なことを除いて、複雑なプロパティの定義は単純なプロパティの定義と変わりません。 次のコードにより、単純な定義と複雑な定義の両方を含む、完全に定義されたプロファイルを示します。

<personalization enabled="true" defaultProvider="Access">
    <providers>
        <add name="Access" type="... " connectionName="..." />
        <add name="SQL" type="... " connectionName="..." />
</providers>
<profile>
    <property 
        name="EmailAddresses"    
        type="System.Collection.Specialized.StringCollection" 
        serializeAs="Xml" 
        allowAnonymous="false" 
        provider="SQL"/>
    <property name="MessagesPerPage" type="int" defaultValue="25" />
    </profile>
</personalization>

この例では 2 つのプロパティしか定義していませんが、多くの場合、プロファイルは多数の値から構成されます。 さらに、これらの値は、多くの場合、請求情報、サイトのレイアウト、および通信選択など、データの論理グループに属します。 プロパティ グループを定義することで、さらに強力な組織のニーズに対応できます。 グループは、<group> タグを使用して内部にプロパティ定義を配置する単なる論理コンテナです。 次のコードにより、グループに編成されたプロパティの一部を示します。 次のセクションでは、グループがコード内でどのように示されるかを説明します。

<profile>
<group name="SiteLayout">
<property name="SyncTOC" type="System.Boolean" defaultValue="true"/>
<property name="ShowNews" type="System.Boolean"/>
</group>
<group name="Correspondance">
<property name="EmailFormat" defaultValue="HTML"/>
<property name="EmailUpdates" type="System.Boolean" 
    defaultValue="true"/>
<property name="UpdateForm" defaultValue="Digest"/>
</group>
</profile>

Profile オブジェクトの使用

ユーザーのプロファイルを定義すると、ページのコーディングを開始して、それらのプロパティから値を読み取ったり、値を書き込んだりできるようになります。 Page クラスにより、HTTPPersonalizationBase のサブクラスである Profile プロパティが公開されます。 web.config を保存すると、IDE によりパーソナライゼーション情報が読み取られ、実行時に Profile オブジェクトがビルドされます。 これは、web.config への変更が直ちに Profile オブジェクトのインターフェイスに反映されることを意味します。 Profile オブジェクトは、プロファイル プロパティごとに、適切に型指定されたプロパティを持ちます。 一部のプロファイル プロパティを構成して、Page の Profile プロパティの IntelliSense メンバの一覧を表示することによって、これをテストできます。

図 1. プロファイル情報が自動的に IntelliSense に表示されます

上の画面のキャプチャでは、最後のコード サンプルで定義したグループおよびプロパティの構造が Profile オブジェクトの物理的な構造に反映されていることがわかります。 また、HTTPPersonalizationBase クラスにより、GetPropertyValue や SetPropertyValue などのメソッドを使用する一般的な方法で、プロパティを処理するための多数のメンバが用意されていることがわかります。

Profile オブジェクトを使用して値を格納および取得することは、適切なプロパティを呼び出すことと同じぐらい簡単です。 ユーザー ID やデータ アクセス用のコードを記述する必要はありません。

パーソナライゼーション フレームワークの拡張

ここまでで、パーソナライゼーション フレームワークの一部として同梱されているプロバイダの使用方法、および Microsoft® .NET Framework の標準の型に基づくプロファイル プロパティを定義する方法について見てきました。 既定の機能でも多数のビジネスのニーズを解決できますが、パーソナライゼーション データをカスタム データ ストアに格納するか、データをユーザー独自の型にカプセル化して格納するために、フレームワークの拡張が必要になる場合もあります。

カスタム プロパティ タイプの実装

既に説明したように、プロファイル プロパティは、シリアル化可能であればどのような型としても定義できます。 さいわいプロパティ型をシリアル化することは、Serializable 属性でデータ定義をマークアップするのと同じぐらい簡単です。 プロパティ定義内で型を使用する場合、型ローダーが型を見つけられるように、完全修飾型参照を使用する必要があります。 次のコードにより、既に説明した通信データをカプセル化する EmailPreferences クラス定義を示します。

namespace ProfileDemo
{
   [Serializable()]
   public enum EmailFormats { Text,HTML }
   
   [Serializable()]
   public enum UpdateForms { Individual,Digest }
   
   [Serializable()]
   public class EmailPreferences
   {
      public EmailFormats EmailFormat;
      public bool EmailUpdates;
      public UpdateForms UpdateForm;
   }
}

クラス以外の型を保存できることがわかります。 この場合、EmailPreferences クラスの一部として 2 つの列挙子が格納されています。 次のコードを使用して、このオブジェクトを使用するようにパーソナライゼーション プロファイルを構成できます。

<property 
    name="Correspondance" 
    type="ProfileDemo.EmailPreferences, ProfileDemo" 
    serializeAs="Binary"/>

カスタム プロバイダの実装

Access プロバイダと SQL Server プロバイダはスタンドアロン Web アプリケーションに非常に適しています。 ただし、より複雑なアプリケーションでは、このプロファイル データが企業内に散在し、多数の異なるデータ ソースに格納されている場合があります。 たとえば、従業員の組織関係のデータが LDAP ディレクトリにあり、給与 ID は DB2 データベースにあるとします。 LDAP ディレクトリを公開するプロバイダと DB2 データベースを公開するプロバイダの、2 つのプロバイダを作成できます。 多くの場合、このデータにアクセスを提供するコンポーネントが既に存在し、プロバイダは単に既存のコンポーネントをパーソナライゼーション フレームワークに含めるラッパーにすぎません。 このようなシナリオをサポートするために、パーソナライゼーション フレームワークでは、System.Configuration.Settings.ISettingsProvideinterface を実装して、簡単に独自のプロバイダを作成できます。 カスタム プロバイダを作成した後で、カスタム型を参照するパーソナライゼーション構成の <providers> セクションにエントリを追加して、カスタム プロバイダを有効にします。

まとめ

ASP.NET 2.0 により、Web アプリケーションをパーソナライズする、新しい優れたフレームワークが提供されます。 このフレームワークにより、ほとんどのデータ型をサポートするのに十分な柔軟性を備え、デザイン時および実行時に引き続きタイプ セーフティを提供する、"両方の環境で最高の" ソリューションが開発者に提供されます。 ASP.NET 2.0 の新しいメンバシップ フレームワークと併せて使用すれば、柔軟でスケーラブルな、非常に関連性の高いエクスペリエンスをユーザーに提供する Web ソリューションを簡単に作成できます。

著者について

Sean Campbell と Scott Swigart は、3 Leaf 社の Senior Principal です。 Sean と Scott は 3 Leaf で、ソリューションのビルドに最新のテクノロジを利用する方法の分析に携わっています。 3 Leaf は、このような知識により、さまざまなコンサルティング、社内教育指導、およびトレーニングのサービスによって、企業が新しいテクノロジをビジネスに統合することを支援しています。 3 Leaf は、最新のテクノロジを開発している企業のために、そのテクノロジのユーザーが実際に実装する際に利用できる、非常に専門的なコンテンツをビルドしています。 Sean と Scott には sean@3leaf.com, scott@3leaf.com までメールで、または 3Leaf の Web サイト www.3leaf.com を通じてご連絡ください。