もうひとつの地球天使のスタスタ
Dayanのブログ S2JDBCを使ってみる
小職は、SE（システムエンジニア）を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。よろしくお願いします。 先日、J2EE勉強会に出たときに、ついでにSeasarのことについてもいろいろと聞いてきた。 新しいプロジェクトでは、SAStruts + S2DAOで行こうと思っていたのですが、中村さん（taediumさん）から、関連するエンティティを一緒に持ってこれるS2JDBCの方が生産性が高いと言われ、また自己参照のテーブルも引っ張ってこれると聞いた。 正直、JPA自体あまり好きではなく、流れるインターフェースといっても、何か擬似SQLっぽいコードというのはどうもという印象を持っていた。なので、LINQなんかも懐疑的な目で見ていた。Criteriaというのもいまいち。どうせSQLにマッピングされるんだったら、SQLで書いたらと思っていた
S2AbstractServiceを用いたAction-Service-Logicパターン - 出羽ブログ
以前に「1.5階層のAction-Service-Logicパターン」を紹介させて頂きました。今回は、このアーキテクチャにS2AbstractService を導入した場合のアーキテクチャについて検討してみました。 主な変更点として、S2AbstractService を導入する場合は、アクションやロジックから直接JdbcManagerを使うこと得策ではないと考え、データアクセスロジックは全てサービスを経由するようになった点です。 まずは、アーキテクチャを図示したものをご覧ください。細かい解説は別エントリにて書かせて頂きますが、エンティティ単位のサービスを採用しつつも、ユースケース固有のロジックはアクションに記述する方法を提示したいと思います。 アーキテクチャ（レイヤ構成図） アーキテクチャ（モジュール相関図）
S2JDBCでHibernateのiterate()相当の処理 - taediumの日記
S2Jdbc で1件ずつフェッチできれば、それで決定なのになぁ。 大量データを検索して処理したい時に、ListだとOutOfMemoryErrorが発生させてしまう場合がある。1行づつデータを取ってくるIteratorもほしい気がする。例えばこんな感じ。 S2JDBCでHibernateのiterate()やscroll()のように1件ずつ処理したい場合ですが、そういうときは最初にidのリストや配列を取得して、そのあと1件ずつ取得して処理するといいと思います。 1+NのSELECTが発生してパフォーマンスが悪いんじゃん？と思うかもしれませんが、S2JDBCは同じトランザクション内でPreparedStatementをキャッシュしているのでパフォーマンスは結構いいです。N件のSELECTはすべて同じPreparedStatementで処理されることになります。 コードはこんな感じになります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CTOA日記:S2JDBCのSQLファイルに変数を使ってSQL文を埋め込む - livedoor Blog（ブログ）
転送中
