連載
|
|
|
●各Application BlockとConfigurationコンソールの依存関係
実は各Application Blockはお互いの機能をシェアし合っている。つまり、各Application Blockは、ほかのApplication Blockに依存しているのだ。従って、Enterprise Libraryを活用するならば、各Application Blockがどのように依存しているのかを理解しておかなければならない。そうしなければ、<正しい>ライブラリ活用は到底できないだろう。
そこで、各Application BlockとさらにConfigurationコンソールとの依存関係を視覚化してまとめた。それが、次の図である。
各Application BlockとConfigurationコンソールの依存関係 |
矢印( や)は依存関係を表している。例えば、「Configurationコンソール」「Configuration Application Block」のように記述しているところは、ConfigurationコンソールがConfiguration Application Blockに依存していること(その機能を使用すること)を意味している。またで表記している依存関係は、Application Blockが使用する機能によって変化することを意味する。つまりそのApplication Blockに含まれるある機能を使うことで、初めてほかのApplication Blockに対する依存関係が生じるのである。なお、図の一番上にあるConfiguration Application Blockを見ると分かるように、すべてのApplication BlockとConfigurationコンソールは、このConfiguration Application Blockを使用している。つまり、Configuration Application Blockは常に必須ということだ。 |
●依存関係によるApplication Blockの自動追加機能
Configurationコンソールは、上の図で示した依存関係を正しく把握しているので、あるApplication Blockを追加すると、それに依存するApplication Blockを正しく、しかも自動的に追加してくれる。
例えば、「Application Exceptionの例外が発生したときにログ出力を行う」という機能をEnterprise Libraryを用いて実現したいとする。その場合、まずは例外発生時に処理を行うために、アプリケーションにException Handling Application Blockを追加する必要がある。これによりそれが使用しているConfiguration Application Blockが自動的に追加される。さらに、Application Exceptionの例外が発生したときにログ出力する設定(=Logging Handlerの追加。詳細は下図参照)を行うと、Logging & Instrumentation Application Blockがまた自動的に追加される。
このようにConfigurationコンソールは、実装したい機能項目を設定していくだけで、その機能が使用するApplication Blockを適切に自動追加してくれるのだ。
これらの追加作業をConfigurationコンソールで実際に行っているのが、次の画面である。
このようにConfigurationコンソールを使えば、非常に簡単に目的の機能をアプリケーションに追加でき、しかも各Application Blockの依存関係の管理も非常に楽である。
●依存関係が生み出すEnterprise Library特有のメリット
しかし、このように各Application Blockがお互いに依存し合っていることが、必ずしも良いことのように思えない読者もいるかもしれない。というのも、依存関係が高まれば高まるほど、それぞれの取り扱いが複雑になってしまうからだ。
だが実は、このような依存関係を持たせたことによって生じたメリットの方が大きいだろう。というのも、各Application Blockがそれぞれに役割分担することで、つまりお互いに統一された明確な依存関係を持たせ、それを管理する仕組みを作り上げることで、それぞれに重複した機能を排除できるというメリットが生まれたからだ。
例えばこれが従来のException Management Application Blockの場合だと、ログ出力機能もそのApplication Block内に実装されていた。Exception Management Application Blockにデフォルトで用意されていたのはイベント・ログへの出力機能だけだったため、テキスト・ファイルやデータベースへ出力する機能については独自に実装するしかなかったのだ。
これは、各Application Block間の依存関係(=役割分担)が統一されていなかったことが原因である。ここに明確な依存関係が存在していれば、そのログ出力機能をほかのApplication Blockの機能に依存させること(つまり、ほかのApplication Blockの機能によって補完すること)ができたはずである。
さらにこういったApplication Block間の依存関係は、ライブラリの習得コストを低減させることにもつながる。つまり重複した機能がないことで、1つの機能について1度理解してしまえば、その機能を利用するすべてのケースでその知識が役立つのである。例えば、ログ出力機能(Logging & Instrumentation Application Block)を理解すれば、通常のログ出力を行うケースでも、(Exception Handling Application Blockを使った)例外処理でログ出力を行うケースでも、その知識が生かせるわけだ。
その最たる例はData Access Application Blockだろう。上で示した「各Application BlockとConfigurationコンソールの依存関係」の図を見れば分かるように、Data Access Application Blockは、ほかの3つのApplication Blockと依存関係を持っている。これはData Access Application Blockの使用方法を一度覚えてしまえば、依存関係にあるほかのApplication BlockからData Access Application Blockの機能を利用する場合でも同じ手順で使用できるということを意味する。
前回、.NET Frameworkの各アプリケーション・サービスはマイクロソフトによって設計方針、実装方法が統一されていることから習熟コストが低減され、結果として開発生産性が向上されるという旨を書いたが、Enterprise Libraryにおいても、こういった設計思想が受け継がれているのである。
以上がEnterprise Libraryとそれに含まれるツール群の概要である。
それではいよいよEnterprise Libraryをインストールする手順について解説していくとしよう。
INDEX | ||
連載:Enterprise Library概説 | ||
Enterprise Libraryの基本ツールと導入手順 | ||
1.Enterprise Libraryを使いこなすための基本ツール | ||
2.各Application BlockとConfigurationコンソールの依存関係 | ||
3.Enterprise Libraryのインストール | ||
「Enterprise Library概説」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|