流れるようにSQLっぽくO/RマッピングできるS2JDBC
流れるようにSQLっぽくO/RマッピングできるS2JDBC：Java初心者が超俊敏にWebアプリを作る方法（最終回）（1/3 ページ） Eclipseプラグイン「Dolteng」のScaffoldという自動生成機能やSeasar 2.4のHOT deploy機能を利用して、DBの参照・更新・削除ができるSAStrutsのWebアプリを作ります。Java初心者だけでなくStrutsに慣れた開発者も必見です 超俊敏にJavaのWebアプリケーションを作るための便利なツールを紹介する本連載も今回で最終回です。 前回の「EL式を拡張したSAStrutsタグ/ファンクションは超便利」では、SAStrutsを利用するうえでJSP記述に便利なSAStrutsのカスタムタグやファンクションについて解説しました。前回までで、SAStrutsをプレゼンテーション層、サービス層、パーシステンス層と分けたときにプ
流れるようなインターフェースをViewのように再利用 - ひがやすを技術ブログ
SELECT文の骨格は同じなんだけど、where句があったりなかったり、Pagingがあったりなかったりするなど、微妙に違うSQL文は良くでてきます。 S2JDBCを使うと、SELECT文の骨格を返すメソッドを用意することで、それをViewのように再利用することができます。例えば、次のような感じ。 protected AutoSelect createView() { return select().leftOuterJoin(dept()) .leftOuterJoin(address()); } public List findAll() { return createView().getResultList(); } public Emp findById(Integer id) { return createView().id(id).getSingleResult(); } pu
2008-02-01
サイオステクノロジーはグルージェントの未来技術に期待し子会社化 サイオースラボみたいな感じかしら。どこかで聞いたような語感ですね。(笑) Seasar2 と Teeda を利用した Web アプリケーションを WebSphere Application Server にデプロイする developerWorksにTeedaをWASにデプロイするための記事が出てます。今後は、定期的にdeveloperWorksに記事を掲載していく予定です。こんなのを書いてほしいとか要望があれば、遠慮なくどうぞ。書くのは私じゃないかもしれないけど(笑)。 「抽象クラスを継承してエンティティ特有のビジネスロジックを実装する」ってことは、そのエンティティは貧血でないドメインオブジェクトってことでしょうか。 SAStrutsの機能リファレンスでは「複数のアクションから共通に使われるような機能は、サービスクラスで実装
【Seasar Conference】「新機能S2JDBCで脱CoC，データベース・プログラミングの生産性を10倍に」---ひがやすを氏
「『流れるようなインタフェース』でデータベース・プログラミングの生産性を10倍にできる」---ひがやすを氏は11月11日，「Seasar Conference 2007 Autumnで，同氏が開発した新データベース・アクセス・ツール「S2JDBC」を披露した。 Seasar2は，ひがやすを氏が開発しているオープンソースのフレームワーク。「つらいJavaから楽しいJavaへ」をモットーに，プログラムの柔軟性を高めるDI（依存性注入）や，デプロイせずにプログラムを修正して実行できるホット・デプロイなど，Java開発の生産性を向上させたり，ストレスなくアジャイルな開発が行えるようにする機能を提供しており，三菱東京UFJ銀行（関連記事）やNTTデータ イントラマート（関連記事）などで採用されている。 Seasar ConferenceはSeasar2を中心とするオープンソース・ソフトウエアの開発を
S2JDBC & Hibernateベンチマークの感想 - ひがやすを技術ブログ
Hibernateは永続コンテキストを管理することがかかるので、大体S2JDBCの2倍前後処理時間がかかりますね。 永続コンテキストの一番の目的は、透過的な更新ですが、これが本当に有効かどうかは疑問です。一見便利に見えるんだけど、裏で勝手に更新されるので、それに振り回されちゃうケースが多いのではないでしょうか。特に関連とCASCADEが絡むとさらに事情を難しくします。 永続コンテキストとエンティティの状態は表裏一体ですが、エンティティの状態遷移に悩まされた人も多いはず。 結局、永続コンテキストは、ちょっと楽をしようとして、多くの複雑性とパフォーマンスの低下をもたらしていると思います。 S2JDBCは、「トラブリにくくする」というテーマがあるので、永続コンテキストは仕様に含めていません。思わぬSQL文が発行されることはなく、開発者が呼び出したクエリしか実行しません。 永続コンテキストのオーバ
S2JDBC & Hibernateベンチマーク その3 - ひがやすを技術ブログ
ManyToOneのfetch joinでは、HibernateがS2JDBCの1.6倍、OneToManyのfetch joinは、HibernateがS2JDBCの1.8倍ほど時間がかかっています。これは大体予想通り。 次は、10000件のうち最後の100件をページングで取得する場合です。HibernateがS2JDBCの2倍ほど時間がかかっています。これも大体予想通り。 次は、10000件の挿入。Hibernateはバッチ更新をするようになっているので、S2JDBCもそれにあわせます。結果は、Hibernateがだいたい2.3倍くらい時間がかかっています。まぁ、予想通り。 次は、10000件の更新。Hibernateが12倍くらい時間がかかっています。Hibernateの時間がかかっているのは、永続コンテキストに格納されているエンティティが更新されているのかをチェックしているためです
S2JDBC & Hibernateベンチマーク その2 - ひがやすを技術ブログ
今度は、Addressを10000件取得してみます。Addressは、EmployeeとOneToOneの関連があり、外部キーを持たない非所有者側のエンティティです。 S2JDBC(0.453489233) 0.454608859 0.451351731 0.454507110 Hibernate(26.278606800) 26.353926022 26.258951969 26.222942410 Hibernateは、S2JDBCより約58倍時間がかかっています。HibernateはOneToOneの非所有者側のエンティティを取得するのは苦手です。10001回のSQLを発行してしまうのです。 下記のSQLは最初に1回発行されます。 select address0_.ADDRESS_ID as ADDRESS1_1_, address0_.STREET as STREET1_, add
2007-10-29 - ひがやすを blog - ERモデルとドメインモデル
エンティティのマッピングで、S2JDBCがJPAと違っているところは、外部キーのプロパティを必要とすることです。 これは、S2JDBCとJPAの根本的なモデリングに対する考えの違いからきています。 S2JDBCは、ERモデルをエンティティに忠実に反映させるという考えです。だから、テーブルのカラムは、エンティティと一対一に対応させます。 それに対しJPAは、ドメインモデルとERモデルを別途作成し、それをO/R Mappingしていきます。重要なのは、ドメインモデルなので、ドメインモデル上必要のない、外部キーに対するプロパティはいらないのです。 どっちがいいのかは、好みの問題ですが、個人的には、ドメインモデルとERモデルという、似てそうで、分析手法が違う2つのモデルを作成するより、ERモデル1つの設計で済ませるほうが楽なので好みです。 データの入れ物にRDBMSを使っているんだから、RDBMS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
