- - PR -
beansについて
1|2|3
次のページへ»
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-01-16 15:39
はじめまして。
MVCのあり方について 研究をしていて疑問があります。 クライアントからServletへ接続し、 Beanに業務処理を依頼、JSPからレスポンスを返す。 といった、基本的な仕組みなのですが、 DB処理の場合のBeanのあり方について迷っています。 BeanにはDB接続、切断、SQLを発行。 といった処理を依頼できますが、 DB接続、切断はお決まり処理のため部品化は 簡単にできますよね。 問題はSQL発行で、 処理によってSQLは数パターン用意され、 各ページによって発行されるSQLは異なる。 ↑このような場合は DB接続、切断beanと 各SQLを発行するbeanに分けたほうがいいのでしょうか。 それとも、DB接続、切断、各SQLを発行するbeanとして ひとつにまとめたほうがいいのでしょうか。 (これだと全てのDB処理を一つのbeanに持たせるのでソースが膨大になる) また、接続切断とSQLのbeanを分けた場合、 さらにSQL処理のbeanを細分化したほうがいいのでしょうか。 (登録処理、更新処理、削除処理といったパターンにわけるなど。) どうも、MVCを提唱しているような機関でも MVCアーキテクチャの概論ばかりで これといった開発手法が見つかりません。 ずいぶん、つっこんだ内容になりますが ご教授お願いします。 [ メッセージ編集済み 編集者: raystar 編集日時 2003-01-17 13:56 ] [ メッセージ編集済み 編集者: raystar 編集日時 2003-01-17 13:56 ] | ||||
|
投稿日時: 2003-01-16 19:09
DBアクセスをbeansでMVCしたいとなると、EJBを使うのが本筋ですね。
とはいえ、EJBサーバを組み込むのは手間とコストがかかるというのなら、EJBのコンセプトだけいただいて、最小限の機能を手作りとなるでしょう。 早い話が、EJBコンテナにあたるクラスを作り、DBへの接続・切断といったお決まりの機能はこちらに持たせます。そして、SQL発行の部分はEntityBeanのようなクラスをアクセス先のテーブルごとに作成し、こいつ任せるわけです。 EntityBeanもどきのクラスには検索と更新のメソッドを持たせ、それらのメソッドにSELECTやらUPDATEのSQLを投げさせます。 EntityBeanもどき用に、共通のインターフェイスか抽象規定クラスを用意してやれば、かなりそれっぽく行くのではないでしょうか。 ま、言うは易しなんですが。 [ メッセージ編集済み 編集者: へげもん 編集日時 2003-01-16 19:13 ] | ||||
|
投稿日時: 2003-01-16 19:57
なるほど!
データベース接続してから 各テーブル用のエンティティーBeanを呼ぶのですね。 そこで新たな疑問なのですが そのエンティティーBeanはどこから呼ばれますか? Servletからのhas-a関係になるのでしょうか。 それともデータベース接続、切断機能をもった クラスとのhas-a関係になるのでしょうか。 エンティティーBeanはサーブレットから直接呼び出しても 問題なさそうですね。 機能分割おもしろいですね!! ありがとうございました。 勉強になります。 もっとほかに、こういうやりかたあるよ。っていう技法があれば お聞きしたいです。 [ メッセージ編集済み 編集者: raystar 編集日時 2003-01-16 19:59 ] | ||||
|
投稿日時: 2003-01-17 01:42
>DB接続、切断beanと
>各SQLを発行するbeanに分けたほうがいいのでしょうか。 >それとも、DB接続、切断、各SQLを発行するbeanとして >ひとつにまとめたほうがいいのでしょうか。 DB接続、切断は、 Connection管理クラスやDataSourceクラスを作る(or使う)のが一般的です。 これはSingletonで実装します。 各テーブルに対しての処理はCRUD(Create , Read, Update, Delete)あわせて、1つのデータアクセスクラスに書くのがわかりやすい。 この場合、データアクセスクラスとコネクション管理クラスの関連は片方向依存ですね。 >どうも、MVCを提唱しているような機関でも >MVCアーキテクチャの概論ばかりで >これといった開発手法が見つかりません。 根気があれば、Jakarta StrutsのサンプルやSun PetStore のソースを追ってみるとか。 | ||||
|
投稿日時: 2003-01-17 07:16
私が今やっているプロジェクトでは、Factoryでもって各DB用(違うDBが使えるようにするため)のDB管理Beanをつくり、その管理オブジェクトでDB接続・切断をできるようにしています。そして各テーブル用のEntityBeanもどきがDB管理BeanからConnectionを取得して、各々SQLを発行しています。
これの利点はDB管理Beanがデータベースの構造を知らなくてもよく、EntityBeanは自由なSQLを発行できます。新しいテーブルを追加した場合、対応するEntityBeanを作成するだけですみます。 時間と労力があれば、StaticなクラスでSQLを自動作成してくれるUtility的なメソッド群を作れればいいなとも思うのですが。そうすれば他のプロジェクトでも使えますからねぇ。 MVCのModel(M)内ではレイヤー構造を使うと便利です。DB接続・切断するレイヤー。その上のEntityBeanレイヤー。そらにその上にのるSessionBeanレイヤー。各レイヤーは隣同士のレイヤーにしかアクセスできないようにすれば再利用性が高まります。(はずです | ||||
|
投稿日時: 2003-01-17 09:50
なるほど。。。
やり方が沢山あって EJBを使う以外は EJBのように動作するクラスをつくるといった 形ですね。 ServletからDB操作Beanを呼び出し そのDB操作BeanのコンストラクタでDB接続、 もしくは、SQL発行メソッドの先頭でDB接続、 終わると切断といった形が シンプルなのかなぁ。とおもいました。 みなさんの書き込みとても参考になります。 もっと、勉強せなば。。。 | ||||
|
投稿日時: 2003-01-17 10:02
こんにちわ。 DB関連、EJBはほとんど知らないのですが教えてください。 なぜConnection管理クラスはsingletonにするのでしょうか? メリット、デメリットは何でしょうか? | ||||
|
投稿日時: 2003-01-17 10:58
singletonについて勉強してみました。 例えばConnection管理クラスが 10つのConnectionオブジェクトのアドレスをもつ コネクションプールだったとすると、 Singletonでない場合、 各サーブレットから10こずつのConnectionオブジェクトを呼び出すことになり、 接続オブジェクトだらけになるようです。 ConnectionオブジェクトはODBCの場合、64個が最大のようです。 この限られた資源を効率よく共有するために Singleton(Static)構造になるのだと理解しました。 覚えたてなんで間違っていたらすみません; | ||||
1|2|3
次のページへ»
