- - PR -
プロジェクトで採用しているデータベースへのアクセス方法(OR Mapping)
| 投票結果総投票数:138 | |||
|---|---|---|---|
| JDBC | 83票 | 60.14% | |
| EJB | 19票 | 13.77% | |
| Torque等のオープンソース | 15票 | 10.87% | |
| 市販のORマッピングツール | 0票 | 0.00% | |
| 独自で開発したフレームワーク | 19票 | 13.77% | |
| その他 | 2票 | 1.45% | |
| |||
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-09-25 20:25
ukさん
返信ありがとうございます。
そうなんですよね! 作った後に私も気づきました^^;
DAOを自動生成するIDEがあるのですね。 JBuilderなのでしょうか? それともIDEがDAOの自動生成するのは当たり前だったりして^^; 自分でもORマッピングツールを作れるような知識とスキルを 持ちたいと思っているのですが、 何か良いサンプル、書籍、サイトなどはご存知でしょうか。 Torqueのソースファイルで勉強すればいいのかな? | ||||||||||||||||
|
投稿日時: 2003-09-26 11:43
洋書ですが、ORマッピングに関してはMartin Fowlerの"Patterns of Enterprise Application Architecture"は良書です。 彼のサイトで関連する記事も読めますので、あわせてごらんください。 http://www.martinfowler.com/ | ||||||||||||||||
|
投稿日時: 2003-09-26 14:54
独自のORマッピングツールを使ってます。
ただし、TorqueとかのようにSQL(RDB)を隠蔽してしまうようなものではなく、かなりの部分は JDBC をそのまま使います。ただ、オブジェクトのメンバーとRDBのカラムの間のデータのやり取りは簡潔に書けます。 その他に、表示形式への変換や、入力データのチェックもスキーマファイル(Torqueに似てます^^)に基づいて行う機能もあるので、小規模なアプリ開発には役に立ってます(と思ってます > 自分でもORマッピングツールを作れるような知識とスキルを・・・ このツルーは以前、開発した仕事の反省から、生産性を上げるにはどういうものが必要かと考えて出来たものです。 Kirikoさんは なぜ ORマッピングツールを作りたいのでしょうか? まずは、その辺を明確にしてから、EJB, Torque 等を検討すると良いのではないでしょうか? | ||||||||||||||||
|
投稿日時: 2003-09-26 15:00
ウチは基本的にJDBCですね。
EJBは、各ベンダーのアプリサーバーはよく対応しているのですが、あまり採用し てないです。 理由としては。 ・基本的に分散要件がない、もしくは、業務ロジックの奥(基本的にDB)がクラス タリングしていないことが多いので、その手前で勝手に分散されると困る ・システム全体の耐久性と性能面の問題 ・メンバーのスキルレベルの問題 ってとこですかね。 あと、1回、試験的に開発してた時、他と干渉して困ったことがありました。 EJBサンプルで「Print("ばーか")」とかやって動かしてたら、他のメンバーのマ シンにいっぱいPrintされてた(^^;;; | ||||||||||||||||
|
投稿日時: 2003-09-26 17:11
これ便利そうですね。 自分が、ORマッピングツールマッピングツールに求めるものは 1.SQLに慣れてるとsql直接たたいたほうが、わかりやすい&早いのでSQLは隠さないでほしい。 2.ResultSetからBeanへの移し変えは面倒なので、自動or設定ファイルでやってほしい。 3.catch、finally文が面倒なのでどうにかしてほしい、とくに、closeがSQLExceptionをなげるがSQLExceptionが発生してもExceptionにくるんで上に投げるぐらいしかやることがない。それなのにコード量が多すぎる。 で、Web+DB PressにのってたseasarというアプリケーションサーバのORマッピングがよさそうだったんですが、時間がなくてダウンロードしただけです。 | ||||||||||||||||
|
投稿日時: 2003-09-27 08:03
yuuさん
返信ありがとうございます。
そうなんですよね。 ORツールとは何か、どんな機能があったらいいのか、といった点が まだ漠然としていてイメージできていないというのが事実です。 ということで、まずはTorqueをダウンロードして 簡単なプログラムを作ってみました。 SQLを書かずに、オブジェクト操作でデータベースにアクセスでき、 とても感動しました。 ただ、複雑なSELECT文を実行したい場合はSQLを 記述しないと難しそうですね。 マスターメンテナンス系のプログラムでは non SQLでコーディングできそうに思いました。 しばらく、Torqueで遊びながら問題点を 把握したいと思います。 | ||||||||||||||||
|
投稿日時: 2003-09-27 08:32
ウラタンさん
書き込みありがとうございます。
そうなんですか。 投票結果も全体に占めるEJB開発の割合が思っていたよりも低かったです。 実プロジェクトでは、JDBC APIを直接利用するケースが多いのですね。
分散要件がないというのが実際多いのでしょうね。 「その手前で分散されると困る」とあるのですが、 これはどのようなケースでしょうか。 ※勉強不足で申し訳ありません
システム全体の耐久性の問題とは、分散すると 通信が発生し、インメモリでオブジェクト同士が やりとりするよりも不安定である ということでしょうか。 また、性能面も同様なことでしょうか。
今回いろいろな方に書き込んでいただきましたが、 この問題を上げる方が意外と多かったのには びっくりしました。 EJB開発に携わったことのあるエンジニアは まだまだ多くはないのですね。 ましてやEJBを利用したシステムのアーキテクチャを きっちりと設計できる方はもっと少なく、 市場価値は高いのでしょうね。 話は変わりますが、 昨日、久しぶりに本屋に行って見ました。 タイトルは忘れてしまいましたが、^^; EJBの設計&Programmingに関するとてもよさそうな本を見つけました。 海外本の翻訳らしく、かなり分厚くて、価格は5、6千円くらい だったと思います。 市場価値の高い"J2EEアーキテクト"を目指す方は、 一度チェックされてはいかがでしょうか。^^ | ||||||||||||||||
|
投稿日時: 2003-09-27 09:36
オープンソースのORツールを
プロジェクトで利用されている方のご意見も 聞かせていただければうれしいです。 よろしくお願いします。 | ||||||||||||||||
