新機能 - ひがやすを技術ブログ

:変数とか$変数とかは、ややこしいかなと思い始めてきました。
JDBC標準の?だけでも良いかも、するとCriteriaアノテーションを使うときは、ARGSアノテーションが不要になります。



public static final String getEmployees_CRITERIA =

  "BETWEEN sal ? AND ?";

public List getEmployees(BigDecimal minSal, BigDecimal maxSal);

LIKEで%を使いたい、あるいは、動的にSQLを組み立てたい場合には、
AbstractDaoクラスを継承して、find(String criteria, Object[] bindVariables),
find(String criteria)を使います。



public abstract class EmployeeDaoImpl

  implements EmployeeDao

  extends AbstractDao {
  public List getEmployees(String ename) {

    return find("ename LIKE '%" + ename + "%'");

    return find("ename LIKE ?",

      new Object[]{"'%" + ename + "%'"});

  }

}

find以外にもBeanを返すfindBean()、単一のオブジェクト(COUNT(*)みたいなやつ)を返すfindObject()も用意します。一応、findMapList()、findMap()もね。
findXxx()は、SELECTではじめて、SELECT文全体も組み立てられるようにするので、Map系メソッドとあわせて、集合演算を簡単におこなえるようになります。

後、DTO(Data Transter Object)によるSELECT文の自動生成もサポートします。
例えば、検索の条件指定画面で、従業員番号、ジョブ、部署番号が入力できるようになっていたとします。これらの入力項目をプロパティに持つDTOを作って、SELECT系メソッドの引数に指定すると、プロパティに入力があれば、WHERE句に加え、入力がなければしかとするSELECT文を自動的に組み立てます。
プロパティ名とカラム名が異なる場合には、COLUMNアノテーションを使います。カラムと関係無いプロパティは無視されます。
StrutsのActionFormもDTOとみなして、そのまま、使うことができます。
いいのかなぁ。微妙な問題だ。
べき論でいうと、プレゼンテーション層のオブジェクトをデータアクセス層に渡すのは間違っています。プレゼンテーション層(Action)で、EntityやDTOに変換すべきです。でもなぁ、知っている上で、特に問題ないことが確認できるなら、認めてもいい気がします。非正規化に近いかも。
それにしても、ActionFormやJSFのバッキングビーンがプレゼンテーション層に依存するような仕様にするのは止めてくれよ。(バッキングビーンは依存しないようにもできるけど)



あんた間違ってますから。Craig切り！！！切腹！！！