Java⇔RDBのMapping-Frameworkを語るｽﾚ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG[Torque]
http://db.apache.org/torque/
http://homepage1.nifty.com/kingyoshi/computer/jakarta/torque.htm
[HYBERNATE]
http://hibernate.bluemars.net/1.html
[CasterJDO]
http://www.castor.org/jdo.html
http://www-6.ibm.com/jp/developerworks/java/021025/j_j-castor.html
[ObJectRelationalBridge (OJB)]
http://www.terra-intl.com/jakarta/ojb/
●コネクション・プーリング
[Jakarta Commons DBCP]
http://jakarta.apache.org/commons/dbcp/
(Jakarta Commons DBCPを使ってみよう。)
http://taka-2.com/jclass/DBCP/
(DBCP利用法 from "『カモン!Commons!』 Jakarta Commonsを使ってスキルアップ" (2002/09))
http://www.mobster.jp/wiki/index.jsp?pid=Commons#i10
0175172
NGNG顧客を表す以下のテーブルがあるとします。
create table employee (
id numeric,
name varchar;
manager_id numeric
);
idはキーであり
nameは名前
manager_idはマネージャのid(自己参照)が入る
//片方のテーブルにe2というエイリアスを設定する
criteria.addAlias("e2", EmployeePeer.TABLE_NAME);
//idが1であるレコードを検索対象とする
criteria.add(EmployeePeer.ID, 1);
//managerのidが1であるレコードを検索対象とする
criteria.add("e2.id", 1);
//自己結合の設定
criteria.addJoin(EmployeePeer.MANAGER_ID, "e2.id");
0176デフォルトの名無しさん
NGNGViewをつかったほうがパフォーマンス的にもいいと思うんだが。
0177172
NGNGあるテーブルを結合させる処理を1000回行ったところ
JDBCを直接操作する処理では平均で1.8秒かかったのに対し
Viewを使用したTorqueでは2.3秒
Viewを使用せずにTorqueの機能を利用して結合させたところ3.4秒でした。
0178デフォルトの名無しさん
NGNG哀しいけれど、O/Rマッピングツールの目的は
ObjectをRDBにどれだけ楽して格納するか、であって、
RDBレコードを如何にしてObjectとして扱うか、が目的では
ないんだよね。
なので、行儀正しく正規化されたDBありき、だと
ツールの特性を梃子にした生産性の向上は実現しづらい。
なにごとも適材適所。
照会系は「JDBC for Reading」で割り切るのもテかな、と
あらゆるオブジェクトを透過的に操作できるのは
理想的だけれど、スループットを考慮にいれると、
現状ではなかなかそうもいかないですよね。
切り分けの境界をどこに置くかがなかなか難しいんだけれど、
そこをきちんと定義できてこそエンジニアかな、とも思う。
私もここらへんはまだまだ手探りなので、
このスレの意見はとても参考にさせてもらってます。
0179172
NGNGTorqueの場合はかなり高速化されたので、こちらはさぞ早いだろうと想像しましたが
何と平均が1.8秒→2.1秒と0.3秒もダウン
0180デフォルトの名無しさん
NGNGどのようなスキーまでどのようなSQLを実行したかによってスピードなんて変わってくるからね。
１０００件で２秒前後ならそんなもんでしょ。
そこまでクリティカルなスピードを求められるならTorqueやJDBCをじかに呼ぶより
EJBを導入することを考えたら？
OJBならEJBと連携できそうだし。
0181172
NGNGEJBも勉強してます。
とりあえず今は、お手軽にDBを操作する方法は無いかな〜と思ってて。
前は「俺実装」のライブラリを一生懸命作ってたんですが、
そんなのより世の中に有る物を使ったほうがいいかなって。
0182デフォルトの名無しさん
NGNGTorqueとOJBを試してみたので(個人的にはOJBが簡単で好き)
今度はExpressoを試してみようと思います。
0183デフォルトの名無しさん
NGNGhttp://219.96.231.242/wizonline/
２ｃｈスレ
http://game3.2ch.net/mmominor/dat/1053536167.dat
0184デフォルトの名無しさん
NGNGtutorial1のサンプルアプリを動作さすところまで実験しました。
でも、最初からアプリを作成する方法がよく分かりません。
PostgreSQLで動かそうと思っても、最初にOJB_HL_SEQテーブルが無いとかのエラーがでるし。
「何そのテーブル？」って感じでした。
一から作成しているチュートリアルって何処かに無いですか？？
0185デフォルトの名無しさん
NGNG＞そこまでクリティカルなスピードを求められるならTorqueやJDBCをじかに呼ぶより
＞EJBを導入することを考えたら？
EJBってJDBC直より速いか？
0186デフォルトの名無しさん
NGNGそれは断じてないでしょう。
0187デフォルトの名無しさん
NGNGEJBもJDBC使ってるのですが
0188デフォルトの名無しさん
NGNGだから、JDBCを直接つかう場合よりもオーバーヘッドが増えて遅くなるって話だろ。
0189172
NGNGSELECTを試したのですが
idとnameを持つテーブルを1000回selectする実験では
JDBC:1311ms
Torque(BasePeer#doSelect()を使用):1505ms
Torque(BasePeer#doPSSelect()を使用):914ms
OJB(PersistentBroker使用):3625ms
と、言う結果でした。
なぜかTorqueのdoPSSelectが最強です。
OJBはリフレクションを多用しているせいか、かなりの低パフォーマンスですね。
0190172
NGNG0191172
NGNG0192デフォルトの名無しさん
NGNG複雑なアプリでどの程度効用が得られるかはかなり疑問だが。
0193山崎渉
NGNGﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
0194デフォルトの名無しさん
NGNG0195デフォルトの名無しさん
NGNG全体的な視野で JDBC直 と EJB(CMPEntityBean) とのパフォーマンス比較を
すべきだと思うよ。自分でJDBC直でちまちま実装するより、EJBコンテナに
任せたほうがより効率的に処理することもあるんでないの?
0196デフォルトの名無しさん
NGNGJDBC for Readingパターンっていうわけじゃないけど、
通常はEJB(EntityBean)を使いつつ、
性能がほしいときに、DAO(JDBC直)って使い分けてる。
0197デフォルトの名無しさん
NGNGhttp://www.javalobby.org/thread.jsp?forum=61&thread=7836
0198デフォルトの名無しさん
NGNG自分のプロジェクトはどう作っていけばいいのかの話の説明がないような?
0199デフォルトの名無しさん
NGNG簡単な例で説明します。
社員の出勤表があります。
テーブル名はもちろん社員番号で割り振っています
カラムは[日付、その日の成績、出勤時間、退勤時間]
（実際には、10項目ぐらいカラムがあります）
となっています。
で、当然同じ形式で社員の人数分あるわけなんですが
このテーブル全てをマッピングしようと思い、
トルクとか使おうと思ってるんですが、
テーブル名ごとにマッピングのクラス書かないといけないんですかね？
いままでJDBC直のばあい、入力した社員番号から
テーブル読み出せるんですが
トルクとかのラッピングツールはテーブルごとに
クラス作りますよね？社員全部のクラス全部作らないといけないんでしょうか；
あとは、テーブルの合成も考えました。カラムは今までのやつ＋社員番号が
入るカラムを追加して（重複許す）全部一つにまとめるって言うやり方です
でもできれば社員ごとに一個ずつテーブル設けたいのです
なんか、うまいやり方ありませんか？
0201デフォルトの名無しさん
NGNGテーブル設計が激しく間違っていると思う
0202デフォルトの名無しさん
NGNG社員ごとにテーブルがあるってこと？
それがそもそもありえない。
RDBMSの勉強からやりなおした方がいいんじゃないの？
0203デフォルトの名無しさん
NGNG入るカラムを追加して（重複許す）全部一つにまとめるって言うやり方です
このテーブルを最初っから作ればいいんじゃないの？
粗度が細かすぎるよねその設計だと・・・・
0204デフォルトの名無しさん
NGNGレスありがとうございます
すいませんDBの勉強しなおしてきます
ちなみに私が設計したわけではありません;;
なので、とりあえずデータ構成の変更を要請してみます
ありがとうございました
0205デフォルトの名無しさん
NGNGだれの設計かは知らんが、もし先輩社員の設計ならば
職場を変えたほうがよいかも。
0206デフォルトの名無しさん
NGNGありがとうございます
いちおう、再設計を任せてくれそうになりました
社員番号と日付を複合キーにして>>203の言うようにしたいと思います
ただ、テーブルの行数が多くなりますが
ｄｂの設計って言うのは何千行でも何万行になったとしても
こういう作り方をした方が良いのでしょうか？
聞いたところによると、最初の設計者が
あまりひとつのテーブルに行が多いとダメ見たいなことを言ったらしくて
そういう使用になったそうです
いちおうオラクル６なんですがオラクルなら何千何万行でもOKですよね
0207あぼーん
NGNG0208デフォルトの名無しさん
NGNGまずはその最初の設計者を殺しましょう。
Oracle（というか最近のフリーのRDBもふくめて）でシステムを組んでて何千何万程度のレコードを心配するなどありえない。
0209デフォルトの名無しさん
NGNG君の会社すさまじくレベル低いよ。大丈夫か?
DB設計の初心者本で正規化について勉強しとけ。
技術力低い分、特定業務に特化しているのだろうから、そのあたり盗んどけ。
自分の思い通りにプロジェクトを進められるのも、
小さな会社の利点だから、いろいろ挑戦してみな。
ある程度力つけたら転職しよう。
0210デフォルトの名無しさん
NGNG言い忘れていましたが、私の会社は基本的には
そういう開発の会社じゃないんです
つまりその、皆はっきり言ってプログラミングとかそういうことは
ド素人でして今回私が抜擢されたのもただ単にちょっと知識
あるからという理由です
自社で済むことは自社内でって言うやり方でして・・・
なので、そのプログラム作ったからといって給料とかupされるわけではありません；；
実際にはセールスが本業なもので・・・
とにかく、後継に迷惑かけないようにしっかりしたもの作ります
転職ですか・・・プログラマはわたしは無理ですね
ココに質問する時点でセンス無いと思ってますから
0211デフォルトの名無しさん
NGNG逆にそんな立場でTorque使おうって技量に感心。
素直にそう思った。エンジニアじゃないのね。
0212209
NGNG少なくともRDBの基礎は学んでおいたほうがいい。
あまり良書とは思わなかったが、入門テキストとして、
「データモデリング 基礎講座」
http://www.seshop.com/detail.asp?pid=1401
最初からしっかりしたものを作るのは不可能なんで、
何度か作り直すつもりで、気軽にね。
自社で開発するにしても一人ぐらい社外の人を入れないと無意味だと思う。
顧客と開発が近いのは利点だけどね。
0213デフォルトの名無しさん
NGNG扱い易いか考えてみ。（それを徹底的にやるのが正規化）
[社員の給料]←[社員の特定]←[部署の特定]←[会社全体]
みたいな。簡単で申し訳無いけど。
0214デフォルトの名無しさん
NGNGJavaなら知っていたので「それでよければやりますが？」
といったら、「じゃ、君やりなさい」と言われました
自社のポータルも私作ったんですが
DB関係はまったくの初めてなのでどうなることか・・・
>>212
システム部といっても私一人ですよｗ
そういう部署設けるぐらいの会社なら
最初から外部に頼んでますよきっとｗ
リンク先覗いてみますありがとうございました
>>213
ありがとうございます参考にさせていただきます
0215213
NGNGする事になると思うけど（笑）その時にはきちんと"全体設計"、"DB設計"、"コーディング"とか、
各フェーズを明確に分けて考えた方がいいよ。それぞれの担当になったつもりで。
その方が完成までの期間とかの見積もりも出せるし。
今回の件では、やりたい事は明確になっているんだろうから、とりあえずDB設計が先か？
その設計次第でコーディングの内容も変わるだろうし。
とりあえず、概算見積もりにはいつも10%上積みの方向で上司に報告っと。（笑
0216デフォルトの名無しさん
NGNGTorque自体のドキュメントやツールがロクに整備されていなかったり
チュートリアルと実際の動作が異なる場面が多かったりなので頑張れ。
0217デフォルトの名無しさん
NGNGまだCastorの方がいいかも。
XMLとの親和性もいいしね。
なんならRelaxerという手もある。
0218デフォルトの名無しさん
NGNGJDeveloper高いけど・・・。
0219デフォルトの名無しさん
NGNGなんでOracle6なんだってつっこみはなし？
あと、さすがに数百万行とか数千万行になるようなテーブルとかならデータ量は気にするよ。
でも、こんなの出てくる場面がかなり限られるので気にしないほうがいいね。
0220デフォルトの名無しさん
NGNG直接JDBCに流し込んだほうが効率いいんだよなー。
それでもプロジェクトで使うって決まってるから使うんだけどね。
レコードをオブジェクトにして、getsetでデータを加工する。
だから件数が多くなればなるほど処理時間が長くなるし、JVMのヒープも
多めにとっとかないとパンクする。
プログラム組んでるとJavaって感じよりCOBOLって感じがする
COBOLもSQL組み込めるけど、Keyをセットしてデータを取り出すって手法似てる
って意味です。
0221デフォルトの名無しさん
NGNGSQLと、プログラムのロジックの記述を
うまく組み合わせることが出来ていたのに
なぜわざわざ。。
仕方ないからやってるけどさ、
逆に、カラム増やすことになって困るのは
CMPや、Torqueのほうだってことだよ
俺個人のプロジェクトのとき
頻繁にテーブル構成変えることあったが
SQL生だとすぐに移行できるが
CMPとかだとちょっとね・・・
動き出すまでに、1時間ぐらい躊躇う
0222デフォルトの名無しさん
NGNG漏れもSQLを生成させて実行、その後はResultSet、
もしくはVectorを返して扱った方がいい。
更新系もSQLを生成してExecuteでぶち込む。
そういうメソッドを持ったクラスの方が
テーブルマップドクラスなんかより
よっぽどビジネスロジックに即している。
SQLについては、ビューやストアドを
使ってシンプルにさせることは
追求しなければならないと思うけどね。
0223デフォルトの名無しさん
NGNGだいたい、JavaにおけるDBのラッピングなんて
JDBCドライバで十分だよ
それにいまのJavaプログラマは
環境依存になるととたんに触手を引っ込める
DD書くのも環境依存なDDが必要になると
いやがるな。まあ、それは俺もそうなんだが・・・
あと個人的な意見では、>>222も書いてるように
SQLの使い方、ストアドの使い方その他もろもろの
細かい設計までやれるのはとても興味深い
パフォーマンスも追及できるしさ・・・
まあ、仕事では再利用性などを考えて
クラスの数が多くなってもいいからデザイン優先じゃない？
まあ、仕事だからやってるし勉強するけど
おれは、今のこの現状を少し遠目に見ている
0224デフォルトの名無しさん
NGNGDBとオブジェクトのマッピングは、所詮
不毛な努力なんじゃないかと。
そういいつつも、何かうまい方法があるんじゃないかと、
つい方法を追ってしまうのだよねえ。
0225デフォルトの名無しさん
NGNGだって、そのままSQL発行すりゃーいいのに
わざわざ、オブジェクトにsetで格納して
向こうに届いたら、getでとりだしてデータベースにインサート
どう考えても二度デマだろ？
向こうで取り出しやすいようにオブジェクトの
構造もワザワザ考えなきゃならんし・・・
DBからデータ取り出すときなんて、
余計なカラムまで取り出したくないのに、
プログラム的には一度に取り出したほうが楽なので
不要なデータも取り出してしまう・・・
しかも、コレクションで帰ってくりゃ
イテレータで取り出し＆キャスト
SQLなら他のUtilクラスにPreparedStatementのSQL文を
static フィールドで保持しておいて置けば
意外にコードはすっきりだ
ストアドもそう。
だいたい、SQL直ってそんなに難しいか？
0226デフォルトの名無しさん
NGNG0227デフォルトの名無しさん
NGNG無意味な事してんな（ｗ
インデックスの張り方とかテーブルの列の順序とかstmt、rsのCloseのタイミングとかは？
0228デフォルトの名無しさん
NGNGSQL知らない奴らと一緒にやってると大変だよな。
0229デフォルトの名無しさん
NGNGおれなんてSELECT UPDATE INSERT DELETE
FROM ORDER BY ぐらいしかつかわんぞ
あとは、データとってくればこっちで何とかするやり方だよ
ストアドだってその場その場で本開けば解決できるしよ
0230デフォルトの名無しさん
NGNG結局俺もJDBC直でやっているわけだが理由は結局O-Rマッピングがかったるいから。
でも、JDBC直だといまいちだなと思うこともまた事実なわけよ。結局Javaの世界
ではやっぱりObjectで扱っているわけだがResultSetからObjectへの変換および
その逆がうざい。かといってODBはよくわからんし。
0231230
NGNG結局
(1)オブジェクトをなんでもかんでも叩きこめる
(2)問い合わせ言語が存在し必要なオブジェクトがひっぱりだせる
の2条件が成立すれば良い訳だ。なんとなくxpath + XMLDatabase + relaxer
でよさげなのが出来そうだな。
0232デフォルトの名無しさん
NGNGオブジェクト投げたら勝手にインサートしてくれるものだと思ってた
たとえば、JavaBean同様にアクセサのあるクラスで
それに加えて内部に情報フィールド持ってて
たとえばデータソースURIやユーザ名パスワード
（この辺はプロパティファイルから読み込みでも可）
でもって、
#insert(Object obj)
とか何とかやれば、自動で内部のフィールドを取り出して
自分でSQLを吐いてくれるやつだとおもってた・・・
Torqueぐらいのマッピング程度ならいままで書いてますよね皆さん？
SQL文発行は一部のクラスに追いやって
そのクラスに対して
insert(String[],int,int)や
select(String tablename,String columnname)
とか言うメソッド作ったりしてませんでした？
俺にとってはなんの新鮮味もありませんでしたよ
0233デフォルトの名無しさん
NGNGすれ違いかもしれんが
おれ、いまXQueryって興味あるんだけど
XMLデータベースサーバーって
どっかにFreeのやつない？
俺が探して見つけたのは有料なんだよなぁ
いまは、え〜と名前忘れたが
＠ITとかで落としたソフトのライブラリ使って
Javaで遊んでいるのだが・・・
0234デフォルトの名無しさん
NGNGXindiceってApacheのXMLプロジェクトじゃなかったっけ。
0235デフォルトの名無しさん
NGNG挿入と、複数条件検索がコストでかいがするんだが。
インデックスをノードのプライマリキー以外に張ると
エライコトになりそうだし。
XMLデータベースと入っても、ストレージのフォーマット
実装は、XMLとは直接関係無いスタイルにしないといかん
ぽな気がするな。
詳しい方、無知なオイラにおしえてちょ。
0236デフォルトの名無しさん
NGNGSQL直書きだと、オブジェクト指向のメリットであるところの
ロジックの局所化が生かせないような気がしなくもない。
ユースケース単位でがしがしSQL作っていると、
いろんな機能にSQLが散らばってメンテナンス不能、みたいなことには
ならないでしょうか。
SQL直書き派は、その辺のところどうやって解決してますか。
0237デフォルトの名無しさん
NGNGやっぱインデックスとキャッシュなんじゃない。
あとは問い合わせ言語の最適化とかのアルゴリズムとか。
0238デフォルトの名無しさん
NGNGあとで拡張するときとかめちゃ便利だよ。
Torqueつかってます。
0239デフォルトの名無しさん
NGNGSQLはプログラムから見ると単なる文字列リテラルでしかないのでロジックとの結合がぜんぜんない。
例えばResultSetから取り出すときに型を間違えてもコンパイラはぜんぜんわからない。
これがマッピングされた環境だとそんなタコミスは即座に判明し、テスト時間も大幅に減らせる。
最悪テーブルの構成が変わったときなど、SQLだとgrep→SQL変更→ResultSet関連変更などなど件数が多くなるほど悪夢のような作業が発生するが、
マッピングされているとその変更の手間は局所的に押さえることができる。
0240デフォルトの名無しさん
NGNG0241230
NGNG>>234もレスってるがXindiceがFreeで使える。ただXQueryはまだ実装されて
いない模様。
Apache Xindice XQueryはまだサポートされていない模様
http://xml.apache.org/xindice/
Xindice:無料で使えるXMLデータベース
http://www.atmarkit.co.jp/fxml/tanpatsu/18xindice/xindice01.html
>>235
XMLデータベースを使用する時って現状だと性能はあんまり関係ない場合に限
られるんじゃないかと思う。XMLデータである限りその分のオーバーヘッドは
どのみちかかるしな。今のところそれなりのデータ量があるようなプロジェク
トで使う気にはなれないな。
ただ、将来的には面白いと思って見ている。Object<->Relationalの変換を
考えるから色々問題が発生するんだよ。それなら根っこから変換不要のデータ
保持形式を考えてみるのも面白いだろ。
0242デフォルトの名無しさん
NGNGeXistはどうよ
0243デフォルトの名無しさん
NGNG0244デフォルトの名無しさん
NGNGを構築しているのか
「Javaアプリケーションシステム」
を構築しているのか
そこら辺の違いだな。
0245デフォルトの名無しさん
NGNGメンテナンス性とかより
学習コストがかかるから避けるっつーのはおかしいかな。
もちろん、プロジェクトメンバー数分ね。
ODB技術全般的にドキュメント類が整備されてないし、
バグもあるだろうし、「なんでできないんだー！」で
結構時間食ったりする。
外部結合とか○○ができないから、そこんとこは
JDBCでよろしくね。なんてことになったら
それこそ、メンテナンス性なんてあったもんじゃない。
実際、システムを保守する人も開発メンバーとは限らないしね。
あと、Strutsほど導入メリットもなく、枯れてないしね。
0246デフォルトの名無しさん
NGNGそれはよく分かる。
RDBのオブジェクトマッピングは、まだ設計技術が
成熟していないような気がするので、
うかつにやってしまうとかえってメンテナンス性が落ちそうな気がする。
この分野はまだまだ試行錯誤の期間が続きそう。
なんか、Strutsとか出る前に、Servletに直接ビジネスロジックを
ゴリゴリ書いていた時代を思い出す。
納期がやたらと早いプロジェクトとかだと、導入リスクが高いので、
SQLゴリゴリの方が、メンテナンス性（メンバーのメンテ能力っていう意味でね）
は高いような気がする。
0247デフォルトの名無しさん
NGNGクエリをクラスにカプセル化するような方法は一般的ではないのでしょうか？
そっちのほうがずっと抽象的な扱いができると思うんですが。
そう思って、SELECT文を記述したXMLからResultSetのラッパークラスを
生成するプログラムを作り中。
0248_
NGNG0249デフォルトの名無しさん
NGNGSqlDataAdapterはとてもじゃないけどカプセル化されてるように見えない。
糞VB再現って感じだなー
0250247
NGNGSqlDataAdapter って３日前に知ったばっかりでした。
0251239
NGNGTorque採用状態からSQL直書きに方針を戻してしまった経験がある…。
0252デフォルトの名無しさん
NGNGそれ自身は何もしてくれない。
DELETE INSERT UPDATEなどの、SQLは自動生成もできるが、手書きが基本らしい。
それで、こいつを経由してDataBaseのメモリーコピーをDataSetというものに入れる。
DataSetに入れてしまえば、DataGridなどのGUI部品と連結ができる。
並び替えやページングのイベントが定義されてるので、
そこにちょこっと、コードを書いてやれば、並び替えやページングのできあがり。
VB厨の俺には小難しくてよく分からんです。
今はEmployeesなどのテーブルクラスと、Employeeレコードクラスを作って、
Employees#selectでEmployeeオブジェクトをhashmapやCollectionに入れてます。
どうやって、DataSetに移行しよう、、、
0253デフォルトの名無しさん
NGNGいやだから、ResultSetをラップするまで行かなくても
SQL文の発行を一部のクラスに追いやることぐらいできるでしょって
言ってるわけさ俺は
そういうクラスを自動で作ってくれるのがTorqueだと俺はおもってる
厳しく言えば、ただそんだけってこと
なので、いままでクラスの設計で半ラッピング状態で
やってきた俺にとって、わざわざTorqueその他のラッピングつーるなんて
使う意味ないねってことよ
＞クエリをクラスにカプセル化するような方法は一般的ではないのでしょうか？
これこそオブジェクト指向でないの？
0254そんな低レベルな話よりも
NGNGhttp://strangeworld-honten.com/cgi-bin/bbs.cgi
0255デフォルトの名無しさん
NGNGやはりソースが分かれると可読性が下がると思う。
0256デフォルトの名無しさん
NGNG使うようにしているので、「東京都に在住のユーザー一覧は以下の
ようにして取得してね」みたいな指示だけ出すようにしてる。
プロジェクトメンバーのメンテナンス能力は別に気にならないなあ。
Pref tokyo = PrefManager.fetchPref(13);
UserCriteria uc = new UserCriteria();
uc.setPref(tokyo);
ArrayList users = UserManager.fetchUsers(uc);
0257デフォルトの名無しさん
NGNGhtmlの特にtableのラッパーが欲しい。
JSPで書いてもhtmlとjavaコードが
乱立するし、書いていて非常に不毛に感じる。
細かな設定のできる（例えばカラーで極細の罫線の代わり
をさせたりする）クラスライブラリないかな。
やっぱ、自力で専用ライブラリつくってるのかな。
0258デフォルトの名無しさん
NGNG普通にカスケードスタイルシートかけばいいだけでわ？
0259デフォルトの名無しさん
NGNGｺﾞﾒｿちょっと、舌足らずだった、
tableを生成するのに
（行追加とかcolspan,rowspanや、極細罫線とか）
ラッパーメソッドで細かな設定
ができるクラスライブラリがないかなと。
0260デフォルトの名無しさん
NGNG明確にほしいものができてるみたいだったら、タグリブを自分でつくれば？
0261デフォルトの名無しさん
NGNGhttp://jakarta.apache.org/ecs/index.html
こーゆーのではなくて？
0262デフォルトの名無しさん
NGNG自分で作っているのかなと聞いてみた。
やっぱ、260も作っているの？
（SQLまでもラップするのがあるのだから、
こういうのもあってもいいのかなと思ったわけ。）
Javaコード内で枠だけ作ってさらにコード内で
値をいれたりとかね。
作っても（つくれるかな？）いいけど
その時間があれば、ベタで書いた方が早いかな．．．
0263デフォルトの名無しさん
NGNGそうそう、こういうのです。
今、ちらっと見ただけですが、
試して遊んでみます。
ありがとうございます。
0264デフォルトの名無しさん
NGNG俺はそこまでのヤツは必要になったことがないから作ったことはない。
が、必要になればまずは探す。
なければ仕方がないのでつくる。
0265デフォルトの名無しさん
NGNGECSって使いどころが微妙じゃない？
0266261
NGNG微妙というか殆ど無いと思う。俺は使いどころイマイチわからん。
ただ、モノ自体は面白いと思うし、将来的には使い道出てくるかもしれないし。
漏れは259が問題にしてるタグとスクリプトコードが混じったりするのは平気。
というかこれからはjellyっスよ（藁
0267デフォルトの名無しさん
NGNG情報激しくキボンヌ
0268デフォルトの名無しさん
NGNG俺もまだまだだとおもう。
ただmiddlegenとかxdocletとか見るにつけ、そういう流れはあるんだろうなーとか。
将来的にORマッピングの強力なツールとなるかもしれない気がする悪寒。
んであとはmavenな。jelly採用してるし、mavenがブレークすれば
ついでにjellyもブレークするんではなかろうか？って勝手に思ってる。
情報はぜんぜんないね。英語の情報もあんま無いし。
1.0リリースするまではCVSでソースとかテストケースをウォッチするぐらいしか
なさそう。テストにあるjellyスクリプトが一番参考になるんじゃないかなぁ。
でもまだタグライブラリの方は動かないの結構多いけど（ｗ
0269デフォルトの名無しさん
NGNGjelly興味はあるんだが取っ付きがなー
0270デフォルトの名無しさん
NGNG説明してもらえる情報源ってないでしょうか？
SQLを知らないJavaPGでも開発できる！
→RDB使うんだからSQLぐらい勉強しろよ！
物理設計が省力化できる！
→RDB使うんだから物理設計ぐらいちゃんとしろよ！
というかE-R系ツールでも結構できるのに。
SQLだと保守性が悪い。
→そのためのドキュメントやん。複雑ならストアドも併用しる。
というわけで、Torqueの特集記事をJavaWorldやWebDBPressで読んだのでつが、
利点が全く理解できないのでつ。
でもJDOは勉強しようと思ってる...
0271デフォルトの名無しさん
NGNGSQL云々かんぬんでなしに、オブジェクト指向における永続化層を自作しなくてよいという話。
これだけでバグと単体テスト工数が3分の1ぐらい軽く減るだろ？
0272270じゃないよ
NGNGつまり、きちんとしたオブジェクト指向による設計を行えば、オブジェクト-DB間の
コードは大体似たようなものになる（というかワンパターンになる）から、そこを
自動生成できるようにします、というのがMapping-Frameworkのコンセプト、という
ように捉えたんだけど、合ってるかな？
0273271じゃないよ
NGNGSQLとJavaはその設計思想からして違うものだからレイヤーとしてO-RMappingを使用して
DBとJavaの層を接続しようと。
EJBなんかもその一部だよね。
0274デフォルトの名無しさん
NGNG単純に、
Person p = new Person();
p.setName("お前");
db.save(p);
Person p2 = db.retrieve(Person.class, "お前");
こういうコーディングができると楽じゃない？
■ このスレッドは過去ログ倉庫に格納されています