解説：MVC＋３層 webアプリの作り方

１．はじめに

１．１ハリウッドの原則

皆さんは、ソフトウェアの開発に関して、「ハリウッドの原則(the hollywood principle)」[資料-1]という言葉を聞いたことがありますか？

Don’t call us, we’ll call you.

文字通り訳せば、「電話はしないでくれ。こちらからするから。」です。なぜ、これを「ハリウッドの原則」というのか知りません。ハリウッドというのですから、映画会社が俳優に対して、「出演の売り込みはしないでくれ、必要ならこちらから電話するから。」というところから来ているのではないかと想像しています。

ソフトウェアの開発に関するＤＩ（かってはＩｏＣと呼ばれた、 *1）[資料-2]技術・手法を言い当てる言葉として、しばしば「ハリウッドの原則」を目にします。確かにＤＩは「“Don’t call us, we’ll call you.”」という技術なのです。逆に「Call us，we wo'nt call you．」という技術もあります。

注 *1:DI(Dependency Injection), IoC(Inversion of Control) 意味は本文を参照して下さい。

前置きが長くなりましたが、この解説はＤＩを使ってコンポーネント化されたwebアプリを開発できるようになることを目標にしています。ただ、具体的なＤＩ用のソフトウェア（ＤＩコンテナ、例ｓｐｒｉｎｇ[資料-3]）を使うところまでは行っていません。これは別に解説する予定です。その前段としてこの解説は次のことを狙っています。

なぜＤＩコンテナ (ｓｐｒｉｎｇのようなソフトウェア）が必要なのか？
ＤＩコンテナは何をしてくれるソフトなのか？
ＤＩコンテナを使うために必要な知識は何か？
設計者ならＤＩコンテナ(ｓｐｒｉｎｇ)を使ったwebアプリをどう設計するのか？

端的にいうとハリウッドの原則を体で理解することです。「“Don’t call us, we’ll call you.”」のｕｓとは誰で、ｙｏｕとは誰でしょうか？ｃａｌｌとは何を意味するのでしょうか。

１．２対象の読者

この解説は次の人を対象にしています。

簡単なwebアプリを書けるが本格的なプログラムの書き方を探している人。
webアプリの設計、特にプログラムの構造を設計しなければならない人。
プログラムが原因で工程が遅れても、プログラムが不透明なために本質的な原因究明ができないことが多々あり、なんとかその状況を改善したい人。

構造の解説ですので言語には直接関係しませんが、例題の言語はJavaを使います。

Javaでwebアプリを開発する場合に共通に使われるJSPとサーブレットについて必要な範囲で知っていることを前提にしています。必要な範囲でというのは、この解説が対象にしている方の立場で違ってきます。

簡単なwebアプリを書ける方は、JSPとサーブレットを一応使えることを前提にしています。設計者は、JSPとサーブレットがwebアプリの中でどんな役割をするものかを理解している必要があります。工程管理者は、深くは必要ありませんが、設計者と似た知識が必要です。

２．ｗｅｂアプリの構造とコンテナ

２．１「MVC + ３層」構造のwebアプリ

「MVC＋３層」構造の３層構造は企業の基幹システムのプログラム構造として推奨されている構造です。図２－１は３層構造の図です。

図２－１３層構造

層構造というのは、隣合う層だけが関連を持ち、隣合わない層は関連しないということです。単に３クラス(群)に分かれているというだけでは層構造とはいえません。

現実のシステムでは、３層構造といいながら、隣り合わない層が関連する構造になっている場合が少なくありません。

注設計パターンの観点でいえば、層構造は「delegate」の構造でたとえば、デコレータパターンやブリッジパターン、ストラテジーパターンとして解釈できます。この解説は設計パターンの抽象的な説明はできるだけ避けて、実際にどうするのかについて説明します。興味のある方は［資料-4］を参考にして下さい。TODO 資料に確認

次に、「MVC構造＋３層」のＭＶＣは設計パターンの一つとして有名なです。本来はGUIを実装する構造ですが、webアプリの構造として使われています。

その元々のクラス図を図２－２に示します。

図２－２一般のMVCパターンのクラス図

webアプリの構造として、MVCと３層を組み合わせた構造が使われます。これを、図２－３に示します。

図２－３ MVC＋３層構造

一般のMVCの場合と違って、webアプリのMVCではビューがモデルに直接作用することはありません。また個々のビュー(具体的な画面)は、モデル(のデータ)全体に比べてごく一部を使う場合がほとんどです。そのため、ビューとモデルの結合を整合する必要があります。このクラスをアクションと呼びます。アクションクラスを加えた、実際に使われるwebアプリのMVCのクラス図を図２－４に示します。アクションはコントローラから見るとモデルに見え、業務ロジックから見ると表示層に見えます。

図２－４現実のMVC２＋３層構造

図２－４の中の線で示されているオブジェクトの関係が簡潔であることが特徴です。

２．２コンテナ

実際の実装では各クラスはコンテナの助けで動きます。図２－５の角丸の四角形はコンテナを意味しています。その中にあるクラスはコンテナによって起動され、直接又は間接にコンテナを参照して目的の処理をします。

図２－５コンテナとMVC＋３層構造

J2EEの仕様ではアクションとビュー、コントローラはwebコンテナの中で動き、業務ロジックとデータアクセスはEJBコンテナの中で動くことになっています。ただし、簡単なシステムでは業務ロジックとデータアクセスはコンテナを使わないで動かすことがあります。

なお、ＥＪＢは欠点が指摘されており［資料-5］、EJBコンテナに代わる軽量のコンテナが使われるようになっています。このコンテナをＤＩコンテナと呼んでいます。ただし、ＤＩコンテナはＥＪＢコンテナの代替として使われますが、利用できる範囲はそれに限ったものではありません。

設計で大切なことは、「アクションとビュー、コントローラ」と「業務ロジックとデータアクセス」を明確に分離することです。

言い換えると、業務ロジックとデータアクセスがwebコンテナを使わなくても動かなければならいということです。この部分はwebの環境で使われることを直接意識しなくて済むようにしなければなりません。たとえば、バッチ環境で動くプログラムから、業務ロジックとデータアクセスを使えるようにすることが必要です。

このことは実際の開発にあたって、業務ロジックだけをテストできることを意味し、３層で構造化することの利点の一つです。

注ＤＩコンテナは業務ロジックとデータアクセス専用ではありませんのでｗｅｂコンテナと協働することがあります。この場合も業務ロジックとデータアクセスがｗｅｂコンテナを直接使わない構造にすることが大切です。

ＥＪＢコンテナ／ＤＩコンテナは必ずしも必要ありません。しかし、コンテナを使わないと設計時に意図した構造が製造時(コーディング時)に壊れるという問題が発生しがちです。コンテナは実行時にアプリのクラスの動きを支援するだけでなく、開発時に特定の構造をプログラマに強制する役割もあります。

構造が崩れた例を図２－６に示します。

図２－６層化されないＭＶＣ２構造

図２－６に示すように、アクションの中に業務ロジックとデータアクセスが入り込み、分離できなくなっています。クラス（群）は構造化（層化）されないで複雑に関係しあい、ｗｅｂコンテナを直接参照するコードになりがちです。こうなるとMVC構造が生かされなくなります。残念ながらこの例はたくさん見かけます。

この解説の例題ではwebコンテナとしてTOMCATを使います。EJBコンテナに相当するコンテナは使いません。コンテナを使わなくても注意深くコーディングすると構造化（層化）できます。ただ、初心者を含む実際の開発の現場で、プログラマ全員に注意深いコーディングを期待するのは無理です。したがって、例題を離れて現実的なｗｅｂアプリを実装するには、何らかのコンテナを使うのが望ましいと考えます。次の章で説明するコンポーネント化を現実的なｗｅｂアプリに適用するにはコンテナが必須でしょう。

３．コンポーネント化

構造として、MVC＋３層構造を前提に実装を考えます。

構造と並んで重要なことはコンポーネント化です。

この解説では業務ロジックやデータアクセスなどMVC＋３層構造の構成要素の内容は説明しません。構成要素の間のインタフェースをどのように実装するかを説明します。

３．１コンポーネント化とは

コンポーネントというのはソースを変更しないで使える部品（クラス群）のことです。コンポーネント化はクラス(群）を差し替えできるように(pluggableに)することです。図３．１－１と図３．１－２はコンポーネントの考え方を示す図です。

図３．１－１コンポーネント化（１）

図３．１－１は、ＤＢＭＳ用のデータアクセスとＸＭＬ用のデータアクセスが業務ロジックと結合できることを示しています。ＤＢＭＳ用のデータアクセスからＸＭＬ用のデータアクセスに、又はその逆に変えるのに業務ロジックのソースは変更しないで済みます。

図３．１－２コンポーネント化（２）

　図3．１－２は異なった業務ロジックに同じＤＢＭＳデータアクセスを使えることを意味しています。業務ロジック１で使ったＤＢＭＳデータアクセスがソースを変更しないで業務ロジック２にも利用できます。

３．２なぜコンポーネント化するのか？

コンポーネント化は再利用性を高める技術の一つです。

図３．１－１の例では、再利用性が生きるのは「業務ロジック」です。「データアクセス」ではありません。

もし、業務ロジックとデータアクセスが一体として作られていると、データアクセス部がＤＢＭＳの場合とＸＭＬの場合の二つの「業務ロジック＋データアクセス」を作らなければなりません。業務ロジックが論理的には変わらなくも二つの場合についてそれぞれ作る必要があります。図３．１－１の方式が実装できると業務ロジックは一つで済みます。

図３．１－２の例では再利用性が生きるのは「データアクセス」です。この場合は、一つのデータアクセスで二つ(以上の)業務ロジックに対応できます。

再利用性を高くすることで過去の開発又は他人（他社）の開発が「財産」として生きてきます。

さらに、コンポーネント化には再利用性以外の効用があります。

開発時にコンポーネント単位でテストできます。
オブジェクト間の依存性が明確になり、そうでない場合より簡潔で緩やかになります。
内容が把握しやすくなります。

図３．１－１の例では、データベースとしてＤＢＭＳとＸＭＬに対応できるプログラムを開発する場合、該当部分をコンポーネント化できると明らかに開発と保守が楽になります。

その結果、品質があがり、工程を短縮し、開発費を低減できます。機能の強化もしやすくなります。

３．３どうすればコンポーネントになるか？

コンポーネント化するには何が必要でしょうか？

以下では、説明を簡潔にするため業務ロジックとデータアクセスとの関連についてだけ取り上げます。

３．３．１直接具現化＋直接参照

まず通常のクラスの参照の仕方を図３．３－１に示します。

図３．３－１直接具現化＋直接参照

業務ロジックの中にクラスをその名前で直接使うコードが含まれています。具体的な例を次に示します。

ExampleDaoImp dao = new ExampleDaoImp (); ... dao.findAllRecords(); ...

注この説明の中でクラス名の最後にImpが付くクラスは具体的なクラスを意味します。

この方式には次の二つの問題があります。

直接具現化 newの引数としてクラス名が使われている。
直接参照 newの左辺の変数のタイプにクラス名が使われている。

この方法を使うとデータアクセスのクラス名が変わると業務ロジックで参照できなくなります。

３．３．２間接具現化＋間接参照

これを避けるために抽象ファクトリパターンを使います。図３．３－２にこの方法を示します。

図３．３－２間接具現化＋インタフェース参照

抽象ファクトリパターンを使った場合のオブジェクトを参照する手順は次の通りです。

オブジェクトの参照手順
① ファクトリに目的のオブジェクトの参照を要求します。
② 該当クラスを具現化します。(注＊１)
③ ファクトリから参照が戻ります。
④ 参照を使って目的のオブジェクトに作用します。

注＊１：初回の要求時又は起動時に１度だけ具現化したものを戻します。

具体的なコーディングの例を次に示します。

IExampleDao dao = ExampleFactory.getDaoInstance(); ... dao.findAllRecords();

注: IExampleDaoはinterfaceを意味します。実装を持つ具体クラスではありません。

この方法はファクトリを実装する必要があります。ただ、TOMCAT(一般にはサーブレットコンテナ)はファクトリと同等の機能を提供していますので、ここではファクトリの詳細は述べません。

３．３．３ＪＮＤＩ＋インタフェース

Ｊａｖａ言語にはオブジェクト(の参照)を取り出すインタフェースとして、ＪＮＤＩが準備されています。ＴＯＭＣＡＴでもこれを実装しています。この方法を図３．３－３に示します。

図３．３－３ JNDI + インタフェース参照

ＪＮＤＩではリポジトリ（オブジェクトの倉庫）に置かれたオブジェクトをキーで取り出すことが出来ます。リポジトリがちょうどファクトリの役割をします。

TOMCATの設定パラメータでリポジトリに置くオブジェクトとそのキーを指定します。この方法でオブジェクトを利用する手順は前項の手順のファクトリの代わりにリポジトリを使う点が違うだけです。

オブジェクトの参照手順
① リポジトリに目的のオブジェクトの参照を要求します。
② 該当クラスを具現化します。(注＊１)
③ リポジトリから参照が戻ります。
④ 参照を使って目的のオブジェクトに作用します。

注＊１：TOMCATではリポジトリへの要求時に１度だけ該当クラスを具現化しているようです。

参照を要求するメソッドはＪａｖａで提供されています(JNDI)。

具体的なコーディングの例を次に示します。

private DbAccessor dbAccessor; ... Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup("java:comp/env"); dao = (IExampleDao) envCtx.lookup("example/dao"); ... dao.findAllRecords(); (必要な例外処理は省略しています)

TOMCATの設定の例は次の通りです。

<Context ...> ... <Resource name=" example/dao " auth="Container" type="jp.co.msm.ExampleDaoImp" factory="org.apache.naming.factory.BeanFactory" /> ... </Context>

具体的には例題の中で説明します。ここでは設定の内容を理解してください。

クラス名を使わないで参照する仕組みを作ることができました。

ＪＮＤＩを使う方法はオブジェクト(の参照)を取り出す処理を業務ロジックに書かねばならないことが欠点です。本来の業務ロジックやデータアクセスに関係のないコードが入り込みます。リポジトリの登録のキーも本来のロジックの中に出てきます。

ＪＮＤＩを使う方法のもう一つの問題は、業務ロジックの中でＪＮＤＩを使うと、業務ロジックを動かすときにTOMCATが必要になることです。業務ロジックとデータアクセスを表示層から分離する原則に反します。これでは、ＭＶＣ＋３層構造とはいえなくなります。

この問題はＪＮＤＩとファクトリを組み合わせて回避できます。ＪＮＤＩをファクトリの中だけで使うことにするのです。ファクトリの具体的な処理は隠蔽されますので、もしバッチ処理で動かそうとする場合はバッチ処理独自のファクトリを書けば業務ロジックとデータアクセスを変更しなくてもバッチ処理で動かせます。

３．３．３ＤＩ＋インタフェース

ＤＩではＪＮＤＩと違って、目的のオブジェクトの参照を要求する必要がありません。ＤＩを使った方法を図３．３－４に示します。

図３．３－４ DI + インタフェース参照

手順は次の通りです。

オブジェクトの参照手順
① 初期化時に該当クラスを具現化します。
② 初期化時に該当クラスの参照を設定します。
(例ではデータアクセスの参照を業務ロジックに設定します)
③参照を使って目的のオブジェクトに作用します。

注＊１：初回の要求時だけで2度目からは初回に具現化したものを戻します。

初期化時に必要なパラメータを与える方法として次の方法があります。

TOMCATの設定を利用する。
初期化マネジャー用のpropertiesファイルを作る。
先の項で説明したＪＮＤＩを使う。

ＤＩをサポートした製品(オープンソース)では、パラメータを与える仕組みを提供していますので、ｗｅｂアプリの開発者はその仕組みを作る必要はありません。

参照を設定されるクラスには、その参照を外部のクラスから設定するメソッド（setter）が必要です。

例を次に示します。

private IExampleDao dao; ... public void setDao(IExampleDao dao){// 参照を設定するためのsetter this.dao = dao; } ... dao.findAllRecords();

パラメータの例を次に示します。これはspringのパラメータの場合です。

<bean name="dao1" class="jp.co.msm.ExampleDaoImp"> </bean> <bean name="service1" class="jp.co.msm.ExampleServiceImp"> <property name="dao"> <ref bean="dao1"/> </property> </bean>

ExampleDaoImpとExampleServiceImpの二つを具現化して、service1にはdao1をdaoに設定する指定をしています。

３．４ハリウッドの原則のレビュー

ここまでの説明でハリウッドの原則、

Don’t call us, we’ll call you.

がＤＩの本質を表していることを理解できましたか？

「us」とはＤＩコンテナのこと、「you」とはその中で動くアプリのクラスのことでしょう。

ＪＮＤＩはどうでしょうか？

Call us，we wo'nt call you．

がＪＮＤＩの本質を表しといえます。

ＤＩはかってＩｏＣと呼ばれていました。時間的に古くからあるＪＮＤＩからＤＩを見ると、確かにＩｏＣと言える思います。

４．クラス構造

具体的な例を示すために、「MVC＋３層構造」のクラスの構造をさらに具体化していきます。

４．１２要求モデル

具体的なwebアプリの使い方（操作法）は複雑です。簡単にするため、その全体を、意味を失わない程度に小さく分けた部分を取り出し、次の操作を考えます。全体はこれらの操作を組み合わせて遂行されていると考えるのです。

要求１

応答１

要求２

応答２

例えば次の場合があります。

要求１：昨日の売上要求

応答１：検索条件(支店名、担当者など)入力画面

要求２：検索条件を入力して、検索結果を要求

応答２：検索結果を表示

目的としている業務を小さく分割したときの、業務的に意味を失わない一部という意味でこれをジョブステップと呼ぶことにします。ジョブステップのシーケンスを図４．１－１に示します。

図４．１－１ジョブステップのシーケンス

２要求からなるジョブステップのモデルを２要求モデルと呼ぶことにします。２要求モデルに基づいたプログラム(の一部)のテンプレートを２要求テンプレートと呼ぶことにします。

複雑な現実のwebアプリの操作の全体を２要求モデルで説明できるとは限りませんが、この解説の中でｗｅｂアプリの構造を考える上で役立ちますのでこのモデルを使います。

４．２２要求モデルの処理シーケンスとクラス

２要求モデルの実装について考えます。

２要求モデルをMVC＋３層構造で処理する場合のシーケンス図を図４．２－１に示します。

図４．２－１２要求モデルのシーケンス

これに関係しているクラスの関係を図にしたものが図４．２－２です。図４．２－２ではクラス名に実装に使う名前に近いものを使っています。図４．２－２上でのクラス名を図４．１－１上に（）を付けて記しています。

注トランザクションの処理はこの解説の趣旨ではないので略しています。実際のアプリでは必要です。コンテナの助けで対応できます。

図４．２－２２要求モデルテンプレートのクラス図

この図の中のクラスの概要は次の通りです。

＃	クラス	概要
１	Controller	コントローラ。これは通常webアプリのフレームワーク(例struts)で提供されますので、開発する必要はありません。コントローラに与えるパラメータは必要です。
２	JSP_n	表示画面を作るオブジェクト。ＪＳＰで作成します。
３	Action_n	要求の処理をするモデル。アクションクラスと呼びます。
４	Service	業務処理を受け持つクラス。一般には一つのクラスとは限りませんが、ここでは一つのオブジェクトとして描いています。
５	Dao	データアクセスを受け持つクラス
６	ActionForm_n	入力データを保持するクラス
７	Dto_n	画面の作成に使うデータもしくはデータベースのデータを保持するクラス
８	DbAccessor	３層の中ではDaoに含まれる。Daoを分割した場合、データへの実際のアクセスを行うクラス。
９	ConnectionBuilder	DBのコネクションのオープン／クローズ

注１：＃６ ActionForm_nと＃７Dto_nはシーケンス図に現れないクラスです。これらは、入力やデータベースのデータの運搬を担います。

２：クラス名に_nが付いているクラスはそれに相当するクラスが複数個あることを意味します。ここの例題では要求に対応して１個存在し、都合２個存在します。

シーケンスの中でDaoと記したクラスはクラスの構成図の中で次の3クラス（群）に分けています。

Dao
DbAccessor
ConnectionBuilder

この解説は３層の各々の層のクラスの作り方を解説していません。ただ、Daoについては一般の場合も概ねこの３層(下部層)に分割されます。該当部分を取り出すと図４．２－３になります。

図４．２－３Ｄａｏの構成クラス

DaoはオブジェクトをDBのレコードに、又はその逆方向に翻訳するクラスです。sqlをここで組み立てます。

DbAccessorは実際にDBにアクセスするクラスです。

ConnectionBuilderはDBをアクセスするのに必要なコネクションのオープンとクローズを受け持ちます。コネクションのプーリングを行う場合はこのクラスで行います。この部分は通常データソースと呼んでいます。外部とのインタフェースは、Javaが標準で提供するDataSourceインタフェースを使います。この解説中ではインタフェースとクラスが混乱するのを防ぐため、クラスはConnectionBuilderと呼んでいます。

DBMSのベンダーがデータソースの部分を提供している場合があります。また汎用で使えるものがOSSとして入手できます。TOMCATにも汎用のものが付いています。

DaoとDbAccessorの部分もOSSとして提供されています。hibernateはその代表的なOSSです。この場合は、hibernate と業務ロジックを仲介するだけの簡単なDaoを作るだけでデータアクセス部を構成できます。hibernateはこの解説の対象外ですので詳しくは触れません。

Serviceのクラス（群）は実際のｗｅｂアプリでは複雑です。これは業務ロジックに依存して変わりますのでデータアクセスのような一般的な形を提示できません。例題では単純なクラスとして、Daoを呼び出しているだけのServiceクラスを使っています。

５．例題

５．１概要

解説にしたがって次の例を示します。

例題１：直接具現化＋直接参照
例題２：JNDI＋ファクトリ
例題３：DI

各例題の構造を補足します。

図５．１－１は直接具現化＋直接参照の構造です。

図５．１－１直接具現化＋直接参照を使ったwebアプリの構成

ActionはService.getInstance()でServiceの参照を取得します。Serviceは、自身の具現化時にDaoを具現化しそれをフィールドに保存します。Dao、DbAcessorも同じ方法で必要な参照を自身のフィールドに設定します。ServiceとDaoのinterfaceを実装する形を使っています。しかし、直接具現化＋直接参照の方式では、interfaceは積極的には役立ってはいません。他の例題と統一するためにこの例題でもinterfaceを使っているだけです。

図５．１－２はJNDI＋ファクトリの構造です。

図５．１－２ JNDI＋ファクトリを使ったｗｅｂアプリの構成

この例題では、TOMCATがServiceからConnectionBuilderまでのクラスを具現化をします。Factoryはそれをstaticブロックで取得し保持します。ActionからDbAccessorクラスは必要な参照を、staticなメソッドを使ってFactoryに問い合わせて取得します。

JNDI(TOMCAT)以外で直接、具体クラスを使っている処理はなくなります。

図５．１－３はDIの構造です。

図５．１－３ DIを使ったｗｅｂアプリの構成

InitializerクラスがServiceからDataSourceまでのクラスを具現化します。そのクラスに関する情報はpropertiesから取得します。この例題ではpropertiesは外部のpropertiesファイルを使っています。

DIを使った場合の特徴は、各クラスから必要な参照を取得する処理がないということです。図５．１－２と比較するとこのことがよく分かります。

Actionが使うServiceの参照はInitializerの実行時には設定できません。図５．１－２と同じ方法で解決できます。しかし、この例題では違った方法を使っています。図５．１－４はその方法です。

図５．１－４ ActionへServiceの参照を設定する方法

この方法は次の通りです。

（１）起動時

InitializerはServiceの参照をサーブレットコンテキストに保存します。

（２） Action実行時

Actionの本来の処理の前に、サーブレットコンテキストからServiceの参照を取得する処理を入れます。

これは、親（ベース）のクラスを作って、そこで行うと通常のActionクラスでは、ＤＩと同じ効果でserviceを参照できます。

listenerはtomcatからwebアプリの起動時に呼び出され、その延長でInitializerが呼び出されます。listenerとInitializerを一体にすることも出来ます。

例題の動かし方は付録で説明します。

注：例題のソース等すべての資料は解説を補足するためだけに書かれたものです。実際のアプリにはそのままで使える内容ではありません。

各例題の共通のソースは次のものです。

共通のクラス

（１）JSP１［v1_a01Example.jsp］

（２）JSP２［v2_a01Example.jsp］

（３）ActionForm1 [Example1ActionForm]

（４）Dto1 [Example1Dto]

（５）ActionForm2 [Example2ActionForm]

（６）Dto2 [Example2Dto]

（７）ConnectionBuilder[ConnectionBuilder]

ユーティリティ

ユーティリティとして次のクラスを使っています。

（１）SetCharsetFilter：ｗｅｂの画面からの文字のエンコーディングを設定し、文字化けを防ぐ。

（２）DbUtil：sqlの組み立てを容易にするためのユーティリティ

（３）ExampleContextListener：例題３でinitializerを起動するためのリスナー。プログラム起動時に一度だけ実行されます。

アクションクラス

アクションクラスは、内容は同じだが継承する親のクラスが違うのでクラス名だけ異っています。

（１）Ａction１

（ａ）N01Example1Action

（ｂ）N02Example1Action

（ｃ）N03Example1Action

（２）Ａction２

（ａ）N01Example2Action

（ｂ）N02Example2Action

（ｃ）N03Example2Action

これらは、実際の開発であれば、一つのクラスにまとめるべきものです。例題では実装法を示すためにまったく同じ処理を重複して書いています。

以上のクラスにはコンポネント化固有の箇所はありません。これらの説明は略します。

次に例題によって異なる部分を概説します。

なお、例示したコードの中で、クラス(タイプ)名の先頭がＩのクラスはinterfaceを意味します。

５．２ BaseAction

各例題ごとに異なるBaseActionがあります。各ベースアクションは業務ロジック(Serviceクラス)の参照の設定の仕方が違っています。

（１）例題１：N01ExampleBaseAction

private IExampleService service; ... service = N01ExampleService.getInstance();

Serviceクラスのスタティックなgetterメソッドを使ってserviceの参照を取得します。

（２）例題２：N02ExampleBaseAction

private IExampleService service; ... service = N02ExampleFactory.getServiceInstance();

ファクトリのスタティックなgetterメソッドを使ってserviceの参照を取得します。

（３）例題３：N03ExampleBaseAction

private IExampleService service; ... service = (IExampleService)servletContext.getAttribute(keyToServiceImpl);

サーブレットコンテキストから参照を取り出します。アクションについては複雑さを避けるためＤＩの手法は使っていません。springはアクションでもＤＩで参照を使える仕組みがあります。

５．３ Service

Serviceクラス自身の具現化の仕方とDaoの参照の設定の仕方が各実装で違います。

（１）例題１：N01ExampleService

private static N01ExampleService instance = new N01ExampleService(); private IExampleDao dao; public static IExampleService getInstance(){ return instance; } private N01ExampleService(){ dao = new N01ExampleDao(); }

シングルトンとして自らを具現化する処理とstaticメソッドでその参照を戻す処理があります。

Dao(N01ExampleDao)をそのクラス名で直接参照して具現化しています。

（２）例題２：N02ExampleService

Serviceクラス自身を具現化する処理はありません。該当する処理はTOMCATが行います。

Daoを参照するメソッドの中で次の処理があります。

IExampleDao dao = N02ExampleFactory.getDaoInstance();

（３）例題３：[N03ExampleService］

private IExampleDao dao; public void setDao(IExampleDao dao){ this.dao = dao; }

Serviceクラス自身を具現化する処理はありません。この処理はイニシャライザー (N03ExampleInitializer)で行われます。

setDaoが定義されています。Initializerがこのメソッドを呼び出してdaoを設定します。Daoを参照するメソッドの中にdaoを取り出す処理はありません。

５．４ Dao

（１）例題１：N01ExampleDao

private DbAccessor dbAccessor; public N01ExampleDao(){ dbAccessor=new DbAccessor(); String driverClassName = "sun.jdbc.odbc.JdbcOdbcDriver"; String url = "jdbc:odbc:Driver={Microsoft Text Driver (*.txt; *.csv)};Dbq=" + dbq + ";Extensions=txt;"; // driverString String username = ""; String password = ""; dbAccessor.setDbParams(driverClassName, url, username, password); }

DbAccessorをそのクラス名を直接参照して具現化しています。DbAccessorもシングルトンとして動作しますが、そのための特別の処理はありません。シングルトンのServiceがDaoを具現化することを前提に作られています。

ドライバのクラス名、dbのurl、ユーザ名、パスワードを設定しています。クラス名だけでなくこれらが変わるとプログラムソースを変更する必要があります。

（２）例題２：N02ExampleDao

Daoクラス自身を具現化する処理はありません。該当する処理はTOMCATが行います。DbAccessorを参照するメソッドの中で次の処理があります。

IDbAccessor dbAccessor = N02ExampleFactory.getDbAccessorInstance();

（３）例題３：N03ExampleDao

private IDbAccessor dbAccessor; public void setDbAccessor(IDbAccessor dbAccessor) { this.dbAccessor = dbAccessor; }

setDbAccessorが定義されていて、Initializerがこのメソッドを呼び出してdbAccessorを設定します。

５．５ DbAccessor

（１）例題１：DbAccessor

public DbAccessor(){ connectionBuilder = new ConnectionBuilder(); } ... public void setDbParams(String driverClassName, String url, String username, String password){ connectionBuilder.setDriverClassName(driverClassName); connectionBuilder.setUrl(url); connectionBuilder.setUsername(username); connectionBuilder.setPassword(password); }

ConnectionBuilderをそのクラス名を直接参照して具現化しています。これもDaoと同じようにシングルトンとして動きますがそのための処理はありません。ServiceからDao、DaoからDbAccessorを具現化することを前提に作られています。

setDbParamsメソッドがあります。これはDaoから呼び出されます。dataSource(connectionBuilder)にドライバーのクラス名、データベースのurl、ユーザ名、パスワードを設定します。

（２）例題２：DbAccessorJndi

DataSource connectionBuilder = N02ExampleFactory.getDataSourceInstance();

ConnectionBuilder(データソース)を具現化する処理はありません。該当する処理はTOMCATが行います。

（３）例題３：DbAccessorDi

private DataSource dataSource; public void setDataSource(DataSource dataSource){ this.dataSource= dataSource; }

Daoクラス自身を具現化する処理はありません。この処理はイニシャライザー (N03ExampleInitializer)で行われます。

setDataSourceが定義されていて、Initializerがこのメソッドを呼び出してdataSource(connectionBuilder)を設定します。

５．６ファクトリ

これは例題２(N02Example)にだけ必要です。

ここで、JNDIを介してリポジトリにアクセスして必要な参照を取り出し、それをstaticなメソッドで取り出せるようにします。各クラスにJNDIを使った処理を入れるより簡潔になります。

JNDIを設定するデータをcontext.xml(contextの部分は変わります)に書き込みます。

ファクトリの主要部分を次に示します。

private static Context envCtx; private static IExampleService service = null; ... static{ try{ Context initCtx = new InitialContext(); envCtx = (Context) initCtx.lookup("java:comp/env"); }catch(NamingException e){ System.out.println("N02ExampleFactory static block,"+e); } try{ service = (IExampleService)envCtx.lookup("n02Example/service"); System.out.println("N02ExampleFactory getServiceInstance succeeded."); }catch(NamingException e){ System.out.println("N02ExampleFactory getServiceInstance,"+e); } } ... public static IExampleService getServiceInstance(){ return service; }

staticブロックでJNDIからServiceの参照を取り出します。その参照を戻すstaticなgetterが定義されています。他のコンポーネントについても同じです。

context.xmlのResourceの定義(抜粋)は次の通りです。

... <Resource name="n02Example/service" auth="Container" factory="org.apache.naming.factory.BeanFactory" type="jp.co.nsp_ltd.a0102.N02ExampleService" /> ... <Resource name="n02Example/dataSource" auth="Container" type="javax.sql.DataSource" driverClassName="sun.jdbc.odbc.JdbcOdbcDriver" url="jdbc:odbc:Driver={Microsoft Text Driver (*.txt; *.csv)};Dbq=C:/@/projEclipse/osss/struts-1.3.8/db/textdb;Extensions=txt" username="" password="" />

最初のResourceはService用です。次のものはdataSource(connectionBuilder)用のものです。

dataSource用のResource要素にはクラスの参照だけでなく、プロパティも一緒に設定されています。例えばurlです。プロパティはJava Beanの命名則に従わなければなりません。たとえば、プロパティurlは名前がsetUrlのメソッド(setter)が該当クラスに定義されていなければなりません。

この命名則に従うと、該当クラスを具現化するときにそのプロパティに値を設定できます。

例題１の場合は、たとえばｕｒｌの値はＤａｏからDbAccessorを経由してdataSourceに設定される方式になっていました。このため、DBMSを変えるためにはDaoのソースを変えなければなりません。

JNDIを使うとこの処理をｗｅｂアプリに書く必要はありません。DBMSが変えるときはResourceの設定内容を変更すれば対応できます。

注：現実のｗｅｂアプリではDBMSに依存する処理がsqlを作るDａｏにもある場合があります。各ＤＢＭＳがそれ固有のｓｑｌの文法を含むからです。これの依存性を下げる工夫は別途必要です。

５．７イニシャライザ

これは例題３(N03Example)にだけ必要です。例題の実装ではパラメータは外部のプロパティファイルから取り出しています。パラメータの供給方法はJNDIを使うなどいくつか考えられます。実際のＤＩコンテナでは、この部分も提供されるので開発する必要はありません。例題はＤＩの初期化の処理の大筋を理解する目的で作っていますので、ＤＩコンテナを使わないで実装しています。n03Example.propertiesがプロパティファイルです。

String serviceImplClassName =properties.getProperty("jp.co.nsp_ltd.a0103.service",dServiceImplClassName); String daoImplClassName =properties.getProperty("jp.co.nsp_ltd.a0103.dao", dDaoImplClassName); ... IExampleService service = (IExampleService)instantiate(serviceImplClassName); IExampleDao dao = (IExampleDao)instantiate(daoImplClassName); ... servletContext.setAttribute(keyToServiceImpl, service); setPropertyByName(propNameDao, IExampleDao.class, dao, service);

プロパティファイルからプロパティの値（完全クラス名）を取り出します。instantiateメソッド（イニシャライザー内のメソッド）を使ってクラスを動的に具現化します。Serviceの参照はサーブレットコンテキストに設定されます。Daoの参照は、ＤＩの約束通りsetDaoを使ってservice(Serviceのインスタンス)に設定されます。

Serviceの参照がサーブレットコンテキストに設定されるのはActionクラスから参照されるからです。ＭＶＣのフレームワークとしてstrutsを使っていますので、Actionクラスの具現化と参照の管理はｗｅｂアプリの開発者に隠れています。そのため、Ａｃｔｉｏｎクラスの中でサーブレットコンテキストをアクセスしてServiceの参照を取り出す処理を書いています。これはＤＩの手法ではありません。

ただし、この処理は親のクラスで行っています。実際のActionクラスを作る人はあらかじめServiceの参照が設定されているとして、つまり、ＤＩを使う場合と同じようにコードを書けます。

実装に依存するプロパティはsetterを呼び出して設定できません。というのは、具現化されたインスタンスの参照のタイプがinterfaceでなければなりません。そのタイプが実装クラスだと実装クラスに依存してしまうからです。参照に対応するinterfaceには実装に依存するプロパティのsetterは定義されていません。ですから、実装に依存するプロパティはsetterで設定できません

このため、実装に依存するプロパティはJavaのreflectionを使って設定します。setPropertyByNameがそのためのメソッドです。

５．８コンポーネントの入れ替え

実際にコンポーネントを入れ替えて見ます。それぞれの実装方式でどんな変更をしなければならないか考えて見ます。

対象のコンポーネントは、DataSourceとします。これまではConnectionBuilderを使っていましたが、TOMCATに付いているDBCPを使います。

（１）例題１ N01Example

DbAccessorを書き換えます。

書き換え後のDbAccessorがダウンロードしたファイルのdev/resources/DbAccessor.javaです。

ConnectionBuilderとDBCPの両方を残さなければならないような、書き換えが出来ない状況であればたくさんの修正が入ります。実際に名前を修正しないでやってみて下さい。

（２）例題２ N02Example

context.xmlのresource設定を変更するだけでDBCPに切り替わります。Resourceでtypeにjavax.sql.DataSourceを指定してfactoryを指定しないで置くとTOMCATの標準値である、org.apache.tomcat.dbcp.dbcp.BasicDataSourceがDataSourceとして使われます。

ソースは変更する必要がありません。

<Resource name="n06Example/dataSource" auth="Container" type="javax.sql.DataSource" driverClassName="sun.jdbc.odbc.JdbcOdbcDriver" url="jdbc:odbc:Driver=... username="" password="" />

この設定は${context}.xmlに含まれていますが、コメントアウトされています。TODO

（３）例題３ N03Example

n03Example.propertiesのdataSourceの値を変更するだけでDBCPに切り替わります。

ソースは変更する必要がありません。

jp.co.nsp_ltd.a0103.dataSource=jp.co.nsp_ltd.a01data.impl.ConnectionBuilder

この設定はn03Example.propertiesに含まれていますが、コメントアウトされています。

６．参考資料

（１）http://en.wikipedia.org/wiki/Hollywood_Principle

（２）Martin Fowler. Inversion of Control Containers and the Dependency Injection pattern,

http://www.martinfowler.com/articles/injection.html,2004

（３）Rod Johnson expert one-on-one J2EE Development without EJB,

pp1-12,2004,wiley publishinghttp://java.sun.com/blueprints/patterns/MVC.html

（４）Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.Design Patterns

Elements of Reusable Object-Oriented Software,pp20-21,1994,Addison-Wesley

（５）Martin Fowler. Patterns of Enterprise Application Architecture,

p100,2003, Addison-Wesley,

(引用)

you don't need EJB to build a good J2EE application, despite what EJB

vendors tell you. You can do a great deal with POJOs(plain old Java

objects) and JDBC

(引用終り）

付録

Ａ．例題のための準備

例題を実習しない方はこの章を読む必要はありません。

例題を動かすために次のソフトウェアが必要です。

（１） eclipse

（２） TOMCAT

（３） struts

簡単なwebアプリなら書ける方を対象にしていますので、eclipseとTOMCATについては説明を省きます。開発環境はeclipseでなくて別の開発環境でもいいです。

strutsについては、ダウンロード後の利用の仕方が、この解説固有の部分がありますので説明します。

２．１ strutsのダウンロード

ダウンロードのサイト (2007.5.17現在)

http://struts.apache.org/download.cgi

struts-1.3.8-all.zip

なお、struts-2.0.6はこの解説では使いません。

Ａ．２ strutsのサンプルを動かす

strutsの確認のためです。他の方法で確認できている場合はこの作業はしなくて済みます。

（１）struts-1.3.8を適当なディレクトリの中で解凍します。

（２）この中の ...\struts-1.3.8\apps\struts-blank-1.3.8.war をtomcatのwebappsディレクトリにコピーします。

（３）tomcatを起動します。

（４）struts-blank-1.3.8.warが実行されていることを確認します。

webブラウザから、次のurlを入力します。

http://localhost:8080/struts-blank-1.3.8/

その結果、「Welcome!」のページが現れるはずです。

（５）tomcatを停止します。

（６）webappsディレクトリ下のstruts-blank-1.3.8.warを削除します。

（７）tomcatのwebappsディレクトリに次の構造が出来ます。

例題は、struts-blankを元に作成しました。ただし、以降の説明と直接関係ありません。

Ａ．３例題をダウンロードする。

TODO リンク [例題ダウンロード] --- Wordの場合はtutwebapp.zipとして保存

解凍します。

Ａ．４テスト用のディレクトリを作成する。

（１）テストに使うディレクトリを作ります。tutwebappとします。

（２）tutwebappの下にダウンロードして解凍したファイル群(ディレクトリを含む)をコピーします。

結果として次の構造になります。

tutwebapp -db -textdb -schema.ini -table7.txt -dev -resources -tutwebappbase.xml -web -html -helloworld.html -images - struts-power.gif -jss -tinyScript.js -pages -confirmContextListener.jsp -confirmKanji.jsp -helloworld.jsp -helloworld2.jsp -v1_a01Example.jsp -v2_a01Example.jsp -styles -tinyStyle.css -WEB-INF -classes -lib -src -java (ソース：別に記載) -index.jsp

ソースは次の通りです。パッケージごとに示します。

（１）jp.co.nsp_ltd.a01cmn

Example1ActionForm.java

Example1Dto.java

Example2ActionForm.java

Example2Dto.java

IExampleDao.java

IExampleService.java

（2）jp.co.nsp_ltd.a01data

IDbAccessor.java

（3）jp.co.nsp_ltd.a01data.impl

ConnectionBuilder.java

DbAccessor.java

DbAccessorDi.java

DbAccessorJndi.java

（4）jp.co.nsp_ltd.a0101

N01Example1Action.java

N01Example2Action.java

N01ExampleBaseAction.java

N01ExampleDao.java

N01ExampleService.java

（5）jp.co.nsp_ltd.a0102

N02Example1Action.java

N02Example2Action.java

N02ExampleBaseAction.java

N02ExampleDao.java

N02ExampleFactory.java

N02ExampleService.java

（6）jp.co.nsp_ltd.a0103

n03Example.properties

N03Example1Action.java

N03Example2Action.java

N03ExampleBaseAction.java

N03ExampleDao.java

N03ExampleInitializer.java

N03ExampleService.java

（7）jp.co.nsp_ltd.util

DbUtil.java

ExampleContextListener.java

SetCharsetFilter.java

なお、この資料の中ではtutwebappのパスを${webproject}で表します。

Ａ．６ libにjarをコピー

解凍したstrutsのｌｉｂディレクトリから次の８個のjarファイルをtutwebapp/WEB-INF/libにコピーします。

＃	ファイル名
１	antlr-2.7.2.jar
２	commons-beanutils-1.7.0.jar
３	commons-chain-1.1.jar
４	commons-digester-1.8.jar
５	commons-logging-1.0.4.jar
６	commons-validator-1.3.1.jar
７	oro-2.0.8.jar
８	struts-core-1.3.8.jar

Ａ．７新しいtaglibのインストール

struts1.3.8に含まれているjstl.jarとstandard.jarは版が1.02で旧いので、新しい版を次からダウンロードします。

http://jakarta.apache.org/site/downloads/downloads_taglibs-standard.cgi

1.1.2.zip

これを解凍します。中に含まれている次の２ファイルを${webproject}/web/WEB-INF/libにコピーする。

＃	ファイル名
１	jstl.jar
２	standard.jar

Ａ．８ webディレクトリをtomcatに登録

エディタを立ち上げ次の内容を入力します。

<?xml version='1.0' encoding='utf-8'?> <Context docBase="${webproject}/web" workDir="${webproject}/web/work" reloadable="false"> <Resource name="n02Example/service" auth="Container" factory="org.apache.naming.factory.BeanFactory" type="jp.co.nsp_ltd.a0102.N02ExampleService" /> <Resource name="n02Example/dao" auth="Container" factory="org.apache.naming.factory.BeanFactory" type="jp.co.nsp_ltd.a0102.N02ExampleDao" dbTableName="table7.txt" /> <Resource name="n02Example/dbAccessor" auth="Container" factory="org.apache.naming.factory.BeanFactory" type="jp.co.nsp_ltd.a01data.impl.DbAccessorJndi" />     <Resource name="n02Example/dataSource" auth="Container" type="javax.sql.DataSource" driverClassName="sun.jdbc.odbc.JdbcOdbcDriver" url="jdbc:odbc:Driver={Microsoft Text Driver (*.txt; *.csv)};Dbq=C:/@/projEclipse/osss/struts-1.3.8/db/textdb;Extensions=txt" username="" password="" />  </Context>

このひな型はダウンロードしたファイルのdev/resources/tutwebappbase.xmlです。次の設定は環境に合わせて変更する必要があります。

（１）docBase="C:/@/projEclipse/osss/tutwebapp/web"

（２）workDir="C:/@/projEclipse/osss/tutwebapp/web/work"

（３）Dbq=C:/@/projEclipse/osss/struts-1.3.8/db/textdb （２か所）

Resourceは例題２に使うための設定です。DataSource用のResourceは二つ設定し、片方はコメントアウトしています。この設定を変更すると実行時に使用するDataSourceを切り替えられることを示すためです。

これを

${tomcat}\conf\Catalina\localhostに適当な名前を付けて、xmlファイルとして保存します。このファイル名(のベース部)はurlの一部になります。ここでは、このファイル名をtutwebappbase.xmlとします。ファイル名(のベース部、例ではtutwebappbase)をこの資料では${contextbase}で表します

Ａ．９ eclipseにwebアプリのテスト用のプロジェクトを作成する。

（１）プロジェクトのタイプはJavaプロジェクトにします。

（２）プロジェクト名はtutwebappprojとします。

（３）既存のソースからプロジェクトを生成を選択して、ディレクトリとして${webproject}を指定します。

（４）「次へ」を押します。

（５）ソースとしては${webproject}/web/WEB-INF/src/javaを指定します。

多分そうなっていますが、そうでない場合は設定して下さい。

（６）${webproject}/web/WEB-INF/classesをコンパイル結果の出力先に指定します。

多分、tutwebappproj/binが設定されていますから変更します。

（７）「完了」を押します。

この時点では未解決参照があるため、作成したプロジェクトはエラーがある状態になっているはずです。

未解決参照を解決するため次の操作をします。

（１）プロジェクトの先頭(tutwebappproj)を選択して、file/propertiesをクリックします。

（２）階層表示からJava Build Pathを選択、右側のタブからsourceタブをクリック。

ここに${webproject}/web/WEB-INF/src/java以外のものがJava Build Pathに登録されている場合はそれを削除します。 ${webproject}/web/WEB-INF/src/javaが登録されていない場合は登録します。

（３）librariesタブをクリック

（４）Add External Jarsクリックし、${tomcat}/common/libから次のjarを選択しbuild pathに追加します。

＃	ファイル名
１	servlet-api.jar
２	naming-factory-dbcp.jar

これで未解決は解決されるはずです。エラーがないことを確認して下さい。

Ａ．１０確認

Ａ．１０．１ htmlでHello World

webブラウザにHello World!と表示してみます。

${webproject}/web/htmlディレクトリにhelloworld.htmlのファイルがあります。

注：webで扱うファイルの名前は文字の大小も含めて同じにする必要があります。

url

http://localhost:8080/ ${contextbase}/html/ helloworld.html

を入力します。

hello worldと表示されるはずです。

Ａ．１０．２ JSPでHello World

ｊｓｐを確認するため簡単なテストをします。

テスト

tomcatを経由してしかテストできません。　

http://localhost:8080/ ${contextbase}/pages/ helloworld.jsp

Hello Worldと表示されるはずです。

Ａ．１０．３ＪＳＰの機能を使ってＨｅｌｌｏ World

先の例はhtmlの拡張子をjspに変更しただけですので、内容はｊｓｐ固有の機能は含まれていませんでした。

この例題では、この解説例題に共通に使うＪＳＰの機能を設定して、Hello Worldを表示してみます。taglib、css、javascriptのテストを含んでいます。

http://localhost:8080/ ${contextbase}/pages/ helloworld2.jsp

Hello Worldと表示されるはずです。

Ａ．１１漢字を入力できるようにする。

これまでの設定で漢字の表示は出来ます。しかし、漢字を入力した場合は「文字化け」します。これを避けるには、サーバに送られてきたデータで使っている文字コードの種類をＪａｖａに明示的に設定しなければなりません。strutsを使っている場合は、ここで示すサーブレットのフィルターの機能を使います。

<filter> <filter-name>SetCharsetFilter</filter-name> <filter-class>jp.co.nsp_ltd.util.SetCharsetFilter</filter-class> </filter> ... <filter-mapping> <filter-name>SetCharsetFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

(ダウンロードしたweb.xmlにはすでに設定されています)

SetCharsetFilterクラスはダウンロードしたファイルに含まれています。これは例題だけのために作ったものです。実際のｗｅｂアプリに使うには改善する必要があります。

確認の方法

http://localhost:8080/ ${contextbase}/pages/confirmKanji.jsp

漢字を含む文字列を入力してそれが正しく表示されると正常に動いています。

Ａ．１２コンテキストリスナーを設定する。

ＤＩを使った例題ではプログラムの起動時にだけ実行される処理を書く必要があります。例題ではこれはコンテキストリスナーを使って実装しています。コンテキストリスナーはｗｅｂアプリが起動されるときに一度だけ呼び出されます。

web.xmlに次のパラメータを設定します。

<listener> <listener-class> jp.co.nsp_ltd.util.ExampleContextListener </listener-class> <listener>

(ダウンロードしたweb.xmlにはすでに設定されています)

jp.co.nsp_ltd.util.ExampleContextListenernが存在しないと、webアプリの起動時にエラーになり、ｗｅｂアプリが立ち上がりません。

ExampleContextListenernにDI用の初期化クラス(Initializer)の初期化メソッド(initProgram)を呼び出す処理を書いています。

確認の方法

http://localhost:8080/ ${contextbase}/pages/confirmContextListener.jsp

confirmContextListener.jspを実行して、画面に説明している内容が表示されると正常に動いています。

Ａ．１３テスト用データベース

データベースの内容として次のwebページのデータを利用させていただきます。

'http://www.stat.go.jp/data/nihon/zuhyou/n0200200.xls

都道府県別人口と人口増加率

textファイルをjdbc-odbcブリッジを使ってdbとして扱います。実際のｗｅｂアプリで利用できるDBMSではありません。ただし、別のｄｂの本格的なDBMSに簡単に切り替えできます。

textファイルはダウンロードした資料のdb/testdbディレクトリの中に含まれているtable7.txtとschema.iniがdbの役割をします。

Ａ．１４クラスに設定されたデータベースのｕｒｌを変更

N01ExampleDao(パッケージjp.co.nsp_ltd.a0101)にデータベースのurlの一部(dbq、テキストファイルを含むディレクトリ)が設定されています。これを環境に合わせて書き換えます。

以上