- - PR -
Struts1.1とDataSourceの取得について
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-10-22 07:14
みなさん、こんにちは。
Struts1.1の勉強をしています。 JNDIを用いたＤＢ接続を行う時に、lookup()メソッドを使ってDataSourceを 取得すると思いますが、これをどのタイミングで行うのが良いでしょうか？ ①Actionサーブレットのフィルタークラスを作成しそこで行う。 ②各イベント時にコールされるActionクラスで行う。 ③各Actionクラスから呼び出されるヘルパークラスで行う。 「③」はトランザクションの保持を考えると違うような気がします。 または、他に何か良いタイミングがあるのでしょうか。 どなたか御知恵をお貸しください。 因みに、DB接続にはO/RマッピングのTorqueを使っているので、 Torque.init("Torque.properties")でDataSourceの取得を行います。 (違ってたらすいません。) | ||||||||||||||||||||||||
|
投稿日時: 2003-10-22 07:42
おはようございます。
１．ServletContextListenerを実装する。 ２．ActionServletのinitメソッドの中で行う。 ３．Struts PlugInで実現する。 があるでしょうか。 １はServlet API2.3をサポートしたサーブレットコンテナ が必要です。 ２の方法はActionServletを拡張する必要があるので、 採用したくないでしょう。 今回はStruts1.1を利用されるとのことですので、 ３が一番簡単なのではないでしょうか。 サービス中に何度も呼ばれるActionクラスで データベース接続の初期化がされているかどうか 判定し、されていなければ初期化するといった 方法でももちろん実現することはできますが、 ・効率性 ・終了処理をどこに記述するのか。 ・初期化処理の記述が分散される可能性がある といった点を考えるとあまりスマートでは ないように感じます。 [編集] Filterに関する記述を削除。 [ メッセージ編集済み 編集者: とまと 編集日時 2003-10-22 07:46 ] [ メッセージ編集済み 編集者: とまと 編集日時 2003-10-22 07:53 ] | ||||||||||||||||||||||||
|
投稿日時: 2003-10-22 13:05
こんにちは、
Struts1.1なら、ActionServletより、RequestProcessorを継承したほうが良いです。 私は、RequestProcessor.init()をオーバライドしてデータソースを取得しています。(super.init()も忘れないように) RequestProcessorはstruts-config.xmlの <controller processorClass="[フルパッケージクラス名]" />で入れることができますので、お手軽です。 考慮する点としては 1. TilesFrameworkを使う場合は、TilesRequestProcessorを継承する 2. 複数モジュール(struts-config.xmlを複数使うとき)の時の対処 になると思います。 | ||||||||||||||||||||||||
|
投稿日時: 2003-10-22 13:56
こんにちは。
今回の場合、どういった点でRequestProcessorのinitメソッドを オーバーライドした方がベターなのでしょうか。 ※Struts1.1ではActionServletを拡張するよりもRequestProcessorを 拡張した方がよいケースは多いとは思います。 (例．processPreprocessフックなど） また、Struts Pluginを利用しないでRequestProcessorを 拡張する方法を選んだ理由も聞かせていただけるとうれしいです。 実は最初RequestProcessorのオーバーライドについても 考えたのですが、 まさにDandanさんのご指摘の通りのことを考慮し、
ActionServletのinitメソッドをオーバーライド方が 考慮すべき点が少ないのでベターかなと思いました。 ただ、これは状況によってどちらとも言えないのでしょうね。 RequestProcessorを拡張せざるを得ない場合は、 ActionServletとRequestProcessorの両方を拡張するのは goodだとは思わないし、 ReqeustProcessorを拡張する予定のないシステムでは、 ActionServletのinitのオーバーライドを選択すれば Dandanさんのご指摘したことを考慮する必要がないので 簡単だということになるのでしょうか。 ただ、私がもし設計するならStruts PlugInを 採用していますね。 以上です。 | ||||||||||||||||||||||||
|
投稿日時: 2003-10-22 17:17
私も Servlet で言う init() が Action に無いものかどうかを
調べたことがありました。 試したことはないですが、Action を継承した中間クラスを作成し、 ここで、setServlet() をオーバライドするのって何か問題が あるのでしょうか？ | ||||||||||||||||||||||||
|
投稿日時: 2003-10-22 18:15
うーん、別にそんなに否定の意図でレス書いたわけじゃないんだけどなぁ。
ですが、大元の
を受けて
と思っただけです。 別に「RequestProcessorへの実装はベストの選択だ！」とは言ってないし、
のとおりだと思います。 --------------------- ちなみに、
ですが、この前関わったプロジェクトでは、Struts上に載せるRequestProcessorをベースにしたコンポーネント(DBアクセスもあるもの)を作成しました。 コンポーネントを使用したいモジュールなら、<controller>にセットし、使用したくないモジュールは指定しないような作りにしたのです(逆に考慮点を利用した)。 そのときは、どうせRequestProcessorに書けばいいや、と思ったし実装する人がstruts-config.xmlに<plug-in>の記述を書かなくてすむ、と思っただけですけどね。 
--------------------- [追記] 先の私の
は*いつも*その様に実装してるような書き方ですね、失礼しました。前回その様に実装しただけで、その前は1.0ベースだったので、普通にAction#getDatasource()だったんですけどね。 [ メッセージ編集済み 編集者: Dandan 編集日時 2003-10-22 18:23 ] | ||||||||||||||||||||||||
|
投稿日時: 2003-10-22 19:02
こんばんは。
なんか私の返信が威圧的（？）だったみたいで、 申し訳ありませんでした。 
私はこういった設計に関する話題が好きで、 設計者が様々な状況でどんな判断で実装方法を選択したのかといった ことに非常に興味があり、 それで質問させていただきました。 私などは、RequestProcessorにはできれば手を付けたくない、 RequestProcessorに密接に関連したコンポーネントは作りたくないと 考えてしまうのですが、 逆にそのような拡張方法をとることでアプリケーションを 記述するプログラマにとっては便利な仕組みを 提供しようという考えなのですね。 ※実は、私も、セッションチェック、権限チェック、サービスチェック、 などの業務共通処理をRequestProcessorで 実行するような仕掛けを作っていたりします（笑）。
これに関しては了解しました。 プロジェクトでRequestProcessor#initを採用されたとのことだったので、 どんな判断で決定したのか興味があったのです。 Dandanさんの気分を害してしまったようで 申し訳ありませんでした。 以上です。 | ||||||||||||||||||||||||
|
投稿日時: 2003-10-23 07:23
とまとさん、Dandanさん、
返信どうもありがとうございます。 DataSourceの取得だけでいろいろな実装方式があるんですね。 恥ずかしながら、Strutsは勉強し始めたばかりなので、 Struts PlugIn(Actionパッケージのインターフェース？)の 存在じたい知りませんでした。 いろいろ試してみたいと思います。 | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。