特集記事

DAOパターンのデメリットを補う「DataAccessMethodパターン」

無駄なクラスを書くのが嫌になったあなたに送るコーディングTips

瑞瑞[著]

2006/06/09 00:00

ポスト

依存性の逆転

　DataAccessMethodパターンとDataAccessObjectパターンの違いについて、依存性という観点から見てみましょう。

　DataAccessObjectは通常BusinessObjectよりも先に定義されます。ですから依存関係は次のようになります。

BusinessObject → DataAccessObject

　DataAccessObjectパターンで最初に作るクラスは、BusinessObjectではなくDataAccessObjectなのです。BusinessObjectを定義する段階で、既にDataAccessObjectは用意されていなければならないわけです。

DataAccessObjectパターン

public class BusinessLogic {
    private Dao dao;
    public void businesslogic(Request req) {
        ……
        ……
        empInfo = dao.selectEmpInfo(prm);
        ……
    }
}

　では、DataAccessMethodパターンではどうなるのでしょうか。

　DataAccessMethodパターンでは、BusinessObjectはデータアクセス処理への依存性が完全になくなります。これは開発の手順として先にBusinessObjectを定義することができるということです。

DataAccessMethodパターン

abstract public class BusinessLogic {
    public void businesslogic(Request req) {
        ……
        ……
        empInfo = selectEmpInfo(prm);
        ……
    }
    abstract protected EmpInfoDto selectEmpInfo();
}

　このクラスを一時的に動かしてみたい場合に、データアクセスする環境が整っていなければスタブを作ればいいのです。

スタブ

public class BusinessLogicStub extends BusinessLogic {
    protected EmpInfoDto selectEmpInfo() {
        EmpInfo empInfo = new EmpInfo();
        empInfo.setData1("hoge1");
        empInfo.setData2("hoge2");
        ……
        ……
        return empInfo;
    }
}

　そして、データアクセス環境が整ったら次のように定義します

MySQL用

public class BusinessLogicMySQL extends BusinessLogic {
    protected EmpInfoDto selectEmpInfo() {
        EmpInfo empInfo = new EmpInfo();
        Connection conn = Pool.getConnection("MySQL");
        ……
        ……
        ……
        return empInfo;
    }
}

　データがスケールアップしたらOracleで作り換えることもできます。

Oracle用

public class BusinessLogicOracle extends BusinessLogic {
    protected EmpInfoDto selectEmpInfo() {
        EmpInfo empInfo = new EmpInfo();
        Connection conn = Pool.getConnection("Oracle");
        ……
        ……
        ……
        return empInfo;
    }
}

　DataAccessMethodとBusinessObjectの依存関係を見てみましょう。

DataAccessMethod → BusinessObject

　DataAccessObjectの依存性が逆転している事を確認できます。実際の開発ではこの依存性が開発プロセスに大きく関係してきます。

まとめ

　いかがだったでしょうか。

　ベースとなるパターンをAbstructFactoryパターンからTemplateMethodパターンに変更するだけでかなりすっきりしたのではないでしょうか。定義すべきクラス数も相当減ったはずです。

　実は、筆者は最近JavaエンジニアがSQLを知らないという声をよく耳にします。なるほど、SQLが定義されているDataAccessObjectクラスをDataAccessObjectジェネレータで自動生成してしまうようなプロジェクトにしか参加していないJavaエンジニアにはSQLの知識が必要なくなります。それによりデータアクセス処理についての知識が求められなくなり、SQLが関心事で無くなってしまったということでしょう。

　しかし、データの永続化方式の選択肢からRDBMSがなくなるということはありないと筆者は考えています。RDBMSは多少のシェアは落とすかもしれませんが、主流であり続けるだけの実績と能力があります。

　DataAccessObjectジェネレータは現在の段階では不十分です。特にパフォーマンスの点で、企業システムに適用すべきでないというケースが多いと思います。とすれば、開発からSQL知識が必要なくなるということはまだまだ先の話という事になります。DataAccessObjectジェネレータがすべてのDataAccessObjectクラスを定義してくれるからといって、SQLの知識を習得する必要がなくなったということはありません。JavaエンジニアにとってSQLの知識はまだ必要なのです。

　いずれにしても、今回はDataAccessMethodパターンの簡単な紹介だけでしたが、開発プロセスでの位置づけや実践的な開発については次回に紹介します。