なぜDIコンテナを使うのか：Spring Frameworkで理解するDI（4）（1/3 ページ）

私がDIコンテナを使う理由

　前回までで、Spring Framework（以下Spring）やDIの概念について説明してきました。最近では、実際の開発現場でもSpringのようなDIコンテナを利用するケースが増えてきているようです。

　現場のエンジニアはDIの“機能”や“役割”は理解できるようです。しかしながら、「なぜそれが必要なのかピンと来ない」「学習してまで導入するほどの効果があるのか疑わしい」という声をよく耳にします。そのほかにも、自分自身はメリットを十分に理解して開発プロジェクトに導入したい気持ちがあるけれど、導入するためには上司や関係者を説得しなくてはならず、どのように説得すればよいか分からないというエンジニアも多いようです。

　そこで今回は、開発案件の関係者に対してSpringの導入を提案し、説得するという観点で、開発現場でDIコンテナを利用する理由や動機を解説します。また、後半では実際に開発現場でSpringを利用してプログラミングを行ったエンジニアの体験談によって、DIコンテナを利用する理由の具体例を紹介します。

■DIコンテナ導入の理由

　DIコンテナを利用する理由（動機）としては、「オブジェクト間の疎結合の実現」や「AOPの実現」など、いままでこの連載で紹介してきた機能を実現できることが挙げられます。しかし、これらの機能は第一線でプログラミングをする人にとっては魅力的な機能であっても、プログラミングをしない人（管理職・顧客など）にとっては、ただの「未知なる驚異」である場合があります。そのような人に対してもDIコンテナの魅力を伝えなくては、DIコンテナを開発プロジェクトには導入できません。しかしここで問題となるのは、DIコンテナがもたらす効果や魅力は、第三者に説明することが難しいものが多いことです。

　そこで、DIコンテナの魅力を第三者に実感的に伝えるために「DIコンテナ誕生の発端」に目を向けてみましょう。DIコンテナの誕生の発端に目を向けるとは、つまりEJBに目を向けることです（EJB 3.0以降はDIコンテナを取り込んだ仕様となるため、以下で「EJB」と呼ぶ場合EJB 2.ｘを指すこととします）。

　そもそもDIコンテナは、EJBに代わるコンポーネントフレームワークとして作られました。つまり、DIコンテナを導入する理由・動機の「みなもと」は、EJBを利用する際の理由・動機と似通っているのです。普及した技術のメリット・デメリットを引き合いに出すことで、より理解を得られやすくなることがあります。

　そういったことから、DIコンテナを導入する動機を説明するに当たっては、説明する側としてもEJBを導入する一般的な動機について理解を深めておきましょう。

　さて、それでは具体的に、開発プロジェクトのアーキテクチャにEJBを導入する動機を、筆者がアーキテクトとしてプロジェクトに参画する場合に検討するメリット・デメリットを例として紹介します。

■EJB導入のメリット

　EJB導入のメリットは以下のように整理できます。

• リモートオブジェクト呼び出しによる物理的なレイヤー分割構成を構築可能。これによって以下の2つのアーキテクチャ設計が可能となる
• Web層とビジネス層の間にファイアウォールを配置することが可能
• スケールアウト（サーバの数を増やすことで、サーバ群全体のパフォーマンスを向上させること）が可能
• 宣言的トランザクションを実現可能

　EJBを利用することで、「別々のサーバマシン上で動作するオブジェクト」、つまり「リモートオブジェクト」を呼び出すことができるようになります。これによって、UIを処理するWeb層とビジネスロジックを処理するビジネス層の稼働サーバを分けるといったように、異なるサーバマシン上にレイヤー（層）構成を実現することが可能です。

　このレイヤー構成を採用する理由として、簡単に思い付くのはスケールアウトが可能であることでしょう。ただし、ビジネスロジック層だけをスケールアウトによって強化したとしても、データベースなどのアプリケーション共有のリソースでボトルネックが先に現れてしまい、全体のパフォーマンスが比例的に向上するということはありません。むしろ、この構成を取るメリットは、UI層とビジネスロジック層の間にファイアウォールを設置できることの方が大きいかもしれません。

　次にEJBでは、どのコンポーネントのどのメソッドでどういった種類のトランザクション管理を行うかという設定が可能です。バグの原因となりやすい低レベルのトランザクション管理をソースコードから分離して管理できることは、ソースコードの可読性向上につながり、開発効率および保守性に良い影響を与えます。

　上記のような機能を実現するためには、EJBは優れたソリューションといえました。事実、アプリケーションにこれらの機能を持たせるためだけに、EJBを利用しているプロジェクトも少なくありません。しかし、EJBには開発効率のうえでデメリットがあります。それらを次で解説します。

■EJBのデメリット

　EJBのデメリットは以下のように整理できます。

• 構成物の多さ（ホームインターフェイス・コンポーネントインターフェイス）
• 環境構築の手間（アプリケーションサーバの必要性）
• ビルドの複雑さ（Ant やXDocletを利用することで手間の軽減をしたとしても依然として煩雑）
• ビルド時間の長さ

　これらのデメリットを総合すると“開発効率の悪さ”がEJBのデメリットであるといえそうです。こういった効率の悪さを軽減・解消するために、DIコンテナは登場しました。EJBのメリットとデメリット、およびDIコンテナがどのようにしてEJBのデメリットを解消しているのかを説明することができれば、DIコンテナを導入するための理由・動機付けとできるのではないでしょうか。また、これらの知識を持つことでDIコンテナを導入すべきプロジェクトと、そうでないプロジェクトの判断材料とすることができるでしょう。

　DIコンテナはさまざまなアイデアでこのEJBの開発効率の悪さを改善してくれています。ここでは、それらのすべてを紹介するのではなく、筆者が最も開発効率に影響を及ぼすであろうと感じる点について説明します。

■目に見えない開発効率の差

　EJBを使った開発とDIコンテナ（Spring）を使った開発の“開発効率”を比べる場合は、「プログラムが作りやすい」ということや「プログラムのコード量が少ない」という比較的目に見えやすい差だけを取り上げるべきではありません。実際に開発を行ってみると「ビルド時間の長さ」や「デバッグのしやすさ」という、開発作業の中で頻繁に発生する日常的な作業の効率において、最も開発効率の違いを感じます。

　以下の表では、実際に同じ仕様のサンプルアプリケーションの開発環境をEJBとSpringで構築するための時間を比較しました。

　以下は1つの例ですが、EJBアプリケーションでは仕組み上、必然的にビルド時間やデプロイ時間が、シンプルなJavaアプリケーションよりも長くかかることは確かです。

　実際の開発では、頭に浮かんだコードを「新たにコーディングしている時間」よりも、「デバッグのためのコーディングを行う時間」や、「バグのある個所を発見するために再ビルドを行う時間」の方が圧倒的に長いことに気付きます。

　筆者がプロジェクトのメンバーに協力を得て実測したところ、1人のプログラマーが丸一日コーディングを行うと、約50回のリビルドを行います。

　つまり、単純に累積するとEJBとSpringの160秒の差は、1日当たり8000秒の差となります。これはおよそ2時間13分の差となります。この待ち時間が実装フェイズの間、プログラマーの数分だけ毎日積み重なるということになります。

　もちろん実際には単純に乗算できるものではありませんし、個人差やアプリケーションの難易度によっても大きく幅があります。しかし、導入の効果を知るまたは説明するというレベルでは参考になるでしょう。

　数字に表れない開発効率の中でもう1つ大事な要素は、プログラマーの集中力です。特にデバッグ作業中は、「5分に1回」や「3分に1回」といった高い頻度でビルドを行います。EJBでの開発のように3分間もの待ち時間が取られてしまうと、何を確認するためにビルドしていたのか、分からなくなってしまうこともしばしばあります。そのためビルド時間が短縮されることで、単純な累積時間の差で見られる以上に、生産性や品質は向上するようです。