- - PR -
beansについて
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-01-17 11:15
平たく言ってしまうとConnectionを管理する人は一人で十分だからです。う〜ん、つまりDBへのConnectionが複数あっても、それらを管理するのは一人だけの方が面倒が少ない。というところです。
Singletonでは一つのオブジェクトをたらいまわしにして使うので、よく管理を担うクラスに使われます。まぁ、Singletonでないといけない理由はありませんが、状況的にSingletonである方が理に適っているなぁというのが私の意見です。 メリット：
デメリット：
こういうデザインパターンに関してすごく詳しくて良いウェブサイト(日本語)がどこかにあったのですけど、誰か知りませんか？Googleで検索しても見つからない・・・。 [ メッセージ編集済み 編集者: H2 編集日時 2003-01-17 11:58 ] | ||||
|
投稿日時: 2003-01-17 14:02
beansの考え方ではなくて、
MVCアーキテクチャの問題になってきましたね。 スレッド名が適切ではなくなってしまいました。。。 | ||||
|
投稿日時: 2003-01-17 15:47
こんにちわ。
皆さんありがとうございます。 singletonの感覚が少しわかった気がします。 確かにConnectionを保持しているオブジェクトが ぽこぽこ生成されてはプーリングの意味がないですね。 | ||||
|
投稿日時: 2003-01-18 11:00
疑問なのですが、DBへの接続はコネクション管理クラスで常に保持する必要があるのですか？
私は通常、コネクション管理クラスは作らずに、各JavaBeansのインスタンスにDB接続を任せています。JavaBeansの各メソッド内で、SQLを発行する直前でgetConnectionして、メソッド終了時にcloseする･･･という具合です。 そのかわりにJNDIに予めDataSourceをバインディングしておき、JavaBeansのコンストラクタでJNDIからDataSourceをlookupしています。JNDI自体がDBへの接続プーリングを管理しているので、わざわざ自作の管理クラスを作ってそこでも接続プーリングの管理を行う必要はないと思っています。 最近はRDBの接続プーリング機能サポートも一昔前とは比べ物にならないくらいに発達してきているし、J2EEのJNDI、COMや.NETのRMといった技術も進歩しているので、「WebアプリケーションではSQLを発行する直前にDBに接続し、使い終わったら即解放する」というのが常識だと思っていたのですが、わざわざJNDIではなく管理クラスを作るメリットはあるのでしょうか？ あと、以下は他人の受け売りなんですが･･･ 最近はSingleton＋Factoryで管理クラス（コンテナ）を作るのが流行って（？）いるようですが、他のBeanを管理するようなコンテナをわざわざ自作するくらいなら素直にEJBコンテナ＋Session Beanを使ったほうがはるかに楽なような気がするのですが、どうなんでしょう？ 苦労して管理コンテナを自作するよりは、既に高機能で安定したコンテナが提供されているのであればそれを使ったほうが、バグも少ないだろうし、車輪の再発明のようなことをしないで済みますよね？ それに機能的にも、管理コンテナを自作してもインスタンス数の管理（プーリング）くらいは簡単に実装できるでしょうけど、EJBの持つejbActivateやejbPassivateのようなライフサイクルの管理機構を自作で実装しようとするとかなり大変だと思います。（たぶん規約付けられたインターフェイスを実装したBeanに対して定期的にコールバックを発行するような形になると思いますが） EJBは「大規模案件でなければ不要」とよくいわれますが、コンテナの管理機能を使うだけでも利用価値は大いにあると思っていますが、どうでしょう？ | ||||
|
投稿日時: 2003-01-18 22:58
>疑問なのですが、DBへの接続はコネクション管理クラスで常に保持する必要があるのですか？
おっしゃるとおり、既存のDataSourceを使えば、自分で作る必要はありません。 何がしかのフレームワークやライブラリを使えば、誰もが使うような、 Connection管理クラスは既に用意されています。 #ただ、Webサーバだけですむところを、EJBコンテナを持ちこもうとするのは、 ちょっと疑問です。 一つのクラスですむところを、 EJBの仕様にのっとり、クラスとインターフェイスを作って、DDを書いて、 JARをつくり、デプロイするのは面倒ではありませんか？ デバッグもIDEでサポートされていないコンテナではままなりません。 管理者がコンテナを管理する手間、開発者がEJBを習得する手間もかかるでしょう。 (開発が容易に行える、洗練されたEJBコンテナと対応IDEがあれば、上記手間もなくなると思いますが、現状どうでしょう) >EJBの持つejbActivateやejbPassivateのようなライフサイクルの管理機構 その機能が必要のは、セッションタイムアウトだけで対処できないような 大規模?プロジェクトでは。。。 というわけで、「メリットも多い」EJBですが、「とても面倒」なのもEJBなので、 トランザクションやセキュリティーがシビアな案件で、 開発要員もいっぱいいるような場合でないと、 "EJBをのデメリット > メリット" かな、というのが現状だと思います。 デメリットも考慮した上で、利用するのが吉と思います。 [ メッセージ編集済み 編集者: みやも 編集日時 2003-01-18 23:25 ] | ||||
|
投稿日時: 2003-01-19 10:31
レスありがとうございます。
JNDIはTomcat 4.0以降でもサポートされるようになったので、DataSourceを使った開発はこれからますます一般的になってくるのかな？と思っています。 EJBについて、以下は主観ですが･･･
私達のプロジェクトではEJBを使った案件と、従来のJavaBeansを使っていた案件での工数・生産性はほとんど同じです。そのため、今ではWeb開発の際には規模の大小・要員数・開発期間のいずれの要因にも左右されずデフォルトでEJBを利用しています。 インターフェイスの作成は定型的かつ機械的なので、そもそもほとんど手間にならないでしょう。それに簡単な自作ウィザードで自動化できるレベルです。JAR化やデプロイの行程もAntに組み込んでしまえば1操作で完了します。附属のデプロイツールを使ってもいいと思います。 「管理者がコンテナを管理する手間」というのは「コンテナ」を「APサーバ」に置き換えても同じなので、EJBなしのWebアプリでも同じことだと思います。 あとよく勘違いされるのですが、ビジネスロジック開発者はEJB特有の技術を習得する必要はありません。ビジネスロジック自体はJavaBeansを使う場合とほとんど同じだからです。開発者はロジックのみに専念できるはずです。逆に開発者がEJBを意識しなければならないのであれば、どこか設計が間違っているのでしょう。 ただデバッグだけは問題かもしれませんね。私達はサーバサイドのデバッグにIDEを使用していないのであまり意識していないのですが、IDEへの依存度が高いプロジェクトでは苦労するのかもしれません。 個人的には 「コンテナを自作する面倒くささ」＞「EJBを導入する際の面倒くささ」 だと思っています。 部品となるBean（ビジネスロジック）だけで済むところを、わざわざ基盤部分（コンテナ）まで作りこむというのがひっかかってしまいます。これは個人的な好みですが。 # 最近「EJB開発は難しい」という思い込みを盾にして、 #「まわりも使ってないし、EJBを使わない今までのやり方でも間に合ってるからいいや」 # という考えの「保守的なJ2EE開発者」が増えてきた気がしています。 # EJBに限らずJ2EEにはJTAやJMSといった素晴らしい能力があり、 # また日々進化を遂げているのに、その進化の流れについていこうとせずに # 過去のJ2EEレベルで満足してしまい、そこから先を習得したがらない技術者が # 増えていることは残念です。使えば便利なのに。 #（中にはJDBC 2.0やDataSourceさえ使わずに、未だにClass.forNameでJDBCやっている強者もいると聞きますが･･･） ちょっと話題からずれすぎてしまいました･･･。 [ メッセージ編集済み 編集者: masaki 編集日時 2003-01-19 10:35 ] | ||||
|
投稿日時: 2003-01-20 17:37
こんにちは
#（中にはJDBC 2.0やDataSourceさえ使わずに、未だにClass.forNameでJDBCやっている強者もいると聞きますが･･･） これって、すでに古い技術なのでしょうか。 入門の技術本くらいしか読んでいないのですが、 ほとんどがClass.forNameでした。 コネクションプールオブジェクトをSingletonで実装すると 一度だけ呼び出すので、コンストラクタでClass.forNameをつかっても 特に問題がありませんでした。 やり方がいろいろあると思うのですが、 やっぱり、新ツール（EJBなど）を使うべき時代になっているのですね。。 | ||||
|
投稿日時: 2003-01-21 02:04
>開発者はロジックのみに専念できるはずです。逆に開発者がEJBを意識しなければなら
>ないのであれば、どこか設計が間違っているのでしょう。 これはとてもいい指針ですね。 そういう設計であれば、開発効率もいいと思います。 >JAR化やデプロイの行程もAntに組み込んでしまえば1操作で完了します (APサーバにもよりますが)ただのWebアプリであれば、パッケージングなしで、 デバッガ上で、ソース編集、デバッグ実行を切れ目なしで行えるので、 開発速度はやっぱり非EJB環境の方が速いかなとは思います。 >「コンテナを自作する面倒くささ」＞「EJBを導入する際の面倒くささ」 ここですよね。 EJBが提供するトランザクションやRDBオブジェクトマッピングを 必要とするかどうか？ 個人的には、まだ、めんどくささの印象をぬぐいきれませんが、 やり方次第では、すいすいいけるのかも。。。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。