連載 Enterprise Library概説 Enterprise Library 3.0が見せる共通ライブラリの未来形 ―― patterns & practicesが描くSoftware FactoriesとEnterprise Libraryの融合というシナリオ ―― アバナード株式会社　市川 龍太（patterns & practices Champion） 2007/01/24

Page1 Page2 Page3

　これまで9回にわたってEnterprise Library（以下EntLib）の概要からEntLibを構成する各Application Blockについて順に解説してきた。その間、EntLibは1.0（2005年1月リリース）から1.1（2005年6月リリース）、そして2.0（2006年1月リリース）へと着実に進化を遂げ、本稿執筆時点（2007年1月）ではEntLib 3.0 CTPがリリースされるに至っている。そこで連載の最終回となる今回は、この新しくリリースされたEntLib 3.0 CTPを基にして、Microsoftが提唱するSoftware Factories構想の中において、EntLibがどのような進化を遂げようとしているのかについて解説していく。

　振り返ってみるとEntLibは常に.NET Frameworkのバージョンと同期する形でメジャー・バージョン・アップを行ってきており、その都度.NET Frameworkそのものが提供する新しい技術要素を取り入れるだけにとどまらずに、その時々のトレンドをもうまく取り入れてきているように思う。例えばEntLib 1.0ではpatterns & practices（以下p&p）が掲げる再利用性や拡張性を持ったアプリケーションの構築ノウハウや自動化されたテストコードの提供（EntLibの開発自体もテスト駆動開発によって行われている）、続くEntLib 2.0では属性ベースのDependency Injection機能を提供するObjectBuilderをEntLibのコア機能として組み込むことでさらなる拡張性を提供するに至っている。

　このp&pの基本方針は（CTPを見る限りでは）EntLib 3.0でも継承されており、先日リリースされた.NET Framework 3.0の新技術要素であるWindows Communication Foundation（WCF）などを取り入れつつ、新しい時代のトレンドであるSoftware Factories（以下SF）的な要素をもたくみに取り入れることで、いままでにない進化を遂げようとしているのである。

　それではEntLib 3.0で新しく提供される予定の機能についていくつか紹介していくとしよう（なお、ここで紹介する機能はCTP版を基にしているため、正規リリース版では変更されている可能性があることにご注意いただきたい）。

■Validation Application Block

　これは任意のルールに基づいて値の妥当性をチェックするためのApplication Blockである。バリデーション（Validation：妥当性検証）のルールを定義する方法には、構成ファイルに記述する方法と属性による方法の2種類がある。ここでは後者の属性ベースで検証を行うためのルール定義の方法について解説する。

　まずバリデーション・チェックの対象となるクラスを定義するためのサンプル・プログラムを以下に示す。

public class Customer {   [NotNullValidator]   [StringLengthValidator(1, 50)]   public string name; }

属性ベースの検証のためのルール定義を付加したサンプル・プログラム

・NotNullValidator属性はNullでないことをチェックする ・StringLengthValidator属性は文字列のサイズが1文字以上、50文字以内であることをチェックする

　上の例ではname変数がNullではなく、かつ文字列のサイズが1文字以上50文字以内であることを宣言している。次に実際にバリデーション・チェックを行うためのサンプル・プログラムが以下になる。

Customer MyCustomer = new Customer(); IValidator<Customer> customerValidator =   ValidationFactory.CreateValidator<Customer>(); ValidationResults results = customerValidator.Validate(myCustomer);

バリデーション・チェックを行うためのサンプル・プログラム

バリデーション・チェックの結果はValidationResults型として返却されることになる。

　このケースで、構成ファイルによって検証する場合には、そのルール定義のイメージは次のようになる。

構成ファイル・ベースで検証を行う場合のルール定義のイメージ

　実際には用途に応じてこれら2つの方法を使い分けていくことになるだろう。

■Visual Studio統合

　各Application Blockの振る舞いを管理するConfigurationコンソールはこれまで単体のツールだったが、EntLib 3.0ではVisual Studio 2005（以下VS 2005）に統合可能なEnterprise Library Configuration Editor（以下Configuration Editor）が提供される。

　以前のバージョンでもVisual Studio .NETのデザイナ上でConfigurationコンソールと同等の管理機能を利用可能にするAvanade Integration Pack for Microsoft Enterprise Library（現在はダウンロードができないようなので、参考URLのみ示す）が公開されていたが、Configuration EditorはEntLib 3.0のインストーラに同梱され、インストール後すぐに利用できるようになる。詳細についてはEnterprise Library 3.0 - Visual Studio-Integrated Configuration Editorを参考にするとよい。

■Strong Naming Guidance Package

　InternalsVisibleTo属性を使用して厳密名付きアセンブリをフレンド・アセンブリ（任意のアセンブリ内のInternalクラスに別のアセンブリからでもアクセス可能にする機能。詳細は「MSDN：フレンド アセンブリ」を参考にするとよい）として登録する際には、公開キー（8bytesの公開キー・トークンではなく、128bytesの公開キーの方）を指定する必要があり、sn.exe（厳密名ツール）を使用した公開キーと秘密キーの生成など、面倒な作業を行う必要があった。

　Strong Naming Guidance Packageはキーの生成からInternalsVisibleTo属性の指定などの一連の作業をある程度自動化してくれるガイダンス・パッケージである。

■Application Block Software Factory（1）

　EntLibはそれ自体拡張性の高いライブラリであるが、その拡張の容易性は個々のApplication Blockが提供する拡張性の範囲内でのカスタム・プロバイダの開発においては十分であっても、完全オリジナルのカスタムApplication Blockの開発においては、お世辞にも容易であるとはいえない一面があった。これはEntLibが再利用性や一貫性を重視する設計方針をベースとしたため、徹底したコンポーネント化が行われていることにも起因している。

　少し詳しく解説すると、EntLibの各Application Blockは内部的にはランタイム・コンポーネント（実行時に利用されるコンポーネント）とデザインタイム・コンポーネント（Configurationコンソールから利用されるコンポーネント）の2つのコンポーネントに大別されており、両コンポーネントとConfigurationコンソールを連携させるには当然これらのコンポーネントの設計・実装方法についてある程度の知識が要求されることになるためだ。

　もちろんこういったコンポーネント化は悪いことではなく、それどころかこの手のライブラリの設計においては推奨されるべき設計方針であるのだが、そもそも根本の問題はこれらコンポーネントを実装していくに当たって、明確な手引きとなるドキュメントなどが不足しているため、ゼロから作るには少し敷居が高いということなのである。

　ちなみにカスタムApplication Blockを開発するに当たって参考になるURLを以下に示す。

• Hands On Labs - Enterprise Library for .NET Framework 2.0 - January 2006
• 開発日記 Enterprise Library（Team EntLib.jpの西崎 公太氏によって運営されているサイト）

　しかしこういった複雑性の問題は別にEntLibに限ったことではなく、第三者が開発した共通ライブラリを拡張するようなシチュエーションでは日常的に見られる光景ではないだろうか？ これは設計者と実装者が異なった場合で、かつ設計ドキュメント、ガイダンス資料が不十分であった場合などによく起こるわけだが、もし十分に資料があったとしても、やはりドキュメントから設計者の意図を読み取ることはなかなか困難なことが多いようである。

　このような設計者−実装者間の意図のミスマッチという、ソフトウェア開発が恒常的に抱える問題に対して、p&pはドキュメントのみによって解決に当たるのではなく、あるツールを提供することで解決を試みようとしている。それがGuidance Automation Toolkit（以下GAT）である。

　そしてApplication Block Software Factory（以下ABSF）とは、カスタムApplication Blockやカスタム・プロバイダの作成に対してGATを適用することで、ゼロから作成するに当たっての複雑さを極力隠ぺいし、開発を容易にするためのパッケージなのである。ABSFを理解するにはGATについてある程度理解しておいた方がよいため、ここで少し話をそらして、まずGATについて簡単に解説する。

INDEX
	連載：Enterprise Library概説
	Enterprise Library 3.0が見せる共通ライブラリの未来形
	1．EntLib 3.0で新しく提供予定の機能
	2．Guidance Automation Toolkit
	3．Application Block Software Factory

　

「Enterprise Library概説」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）