1

次の疑問があります。Java アプリケーションから DB にクエリを実行する必要がある場合、いくつかの方法があります。私はいくつかのアプローチを考え出しましたが、それぞれに短所があります。

最初のものは、例えばクラスがあります。これは、接続などの管理の詳細を隠しながらQueryManager、照会機能を提供します(一種のファサード パターン)。DB と対話する必要がある場合は、クエリを文字列として渡し、.executeUpdate(...)executeQuery(...)ResultSet

私が見ている問題は、DB が変更された場合、DBMS であれ DB 自体であれ、ファイルごとに SQL を変更することになります。これは大きな依存関係だと思います。また、DB の構造をすべての人に公開し、各クラスでResultSet. 一方、クラスのモデル (私はMVC Patternのファンです) がパッケージの可視性を持つ可能性があるため、この方法を使用してより高いモジュール性を実現できます。

私の頭に浮かんだ 2 番目のアイデアはQueryManager、クエリのメソッドを提供する代わりに、必要なメソッドを提供するクラスを作成することでした。つまり、DB を使用する必要があるたびに、必要な情報を返す SQL を含むメソッドをこのクラスに作成します。ResultSetしかし、ここで直面している問題は、必要なデータを返すかモデルを返すかを選択する必要があることです。
前者は、すべての SQL が 1 つのクラス/ファイルに含まれているため、DBMS との依存関係が広範に広がっていないため、前の例よりもクラスの DB への依存度が低くなります。ただし、DB 構造との依存関係は依然として存在し、DB 構造もすべての人に公開しています。
後者は、これらのモデルがもはやパッケージの可視性ではないことを意味します。それらはパブリックでなければならず、任意のクラスがそれらを変更できるようにし、カプセル化を解除します。

以前の問題をすべて解決する他のアプローチはありますか? そうでない場合、どちらがより良いアプローチだと思いますか?

絶対的な答えがあるとは思いませんが (あるかもしれません)、DB の構造と DBMS の両方に変更が加えられることを期待していると言わざるを得ません。これはあなたの答えに役立つかもしれません。しかし、私は同じ疑問を持って他のプロジェクトにいる可能性があるため、できるだけ一般的にするようにしてください。ただし、同じ制限はありません。

4

5 に答える 5

1

2 つ目は良い方法です。データ アクセス オブジェクト (DAO) でデータ アクセス メソッドを抽出する必要があります。これにより、アプリケーションの残りの部分が永続性関連の問題から分離されます。また、DAO は、結果セットではなく、確実にオブジェクトを返す必要があります。

これには、次の利点があります。

  • 懸念と責任の切り離し
  • スキーマが変更されたときにアプリケーションの残りの部分を簡単に進化させる
  • JDBC の代わりに ORM を使用してデータベースにアクセスすることを選択した場合、アプリケーションの残りの部分をより簡単に進化させる
  • 永続化コードが機能コードと混合されていないため、クエリ (および永続化レイヤー全般) の単体テストが容易になります。
  • データベース内の実際のデータをテストする必要がなく、モック DAO を挿入してデータを提供できるため、ビジネス (サービス) レイヤーの単体テストが容易になります。
于 2012-06-04T14:43:45.797 に答える
1

私はあなたのアプローチのどちらも好きではありません。

それらすべてを処理する単一のインターフェース、つまりジェネリック DAO を作成できます。アドホック クエリや任意のオブジェクトへのマッピングが許可されていないため、完全な回答を意図していない簡単な例を次に示します。

public interface GenericDao<K, V> {
    List<V> find();
    V find(K key);
    K save(V value);
    void update(V value);
    void delete(V value);
}

永続化クラスとモデル クラスの間には明確なインターフェイスが必要です。後者は前者について知る必要はありません。

永続層を許可しResultSetたり、Statement漏らしたりしないでください。

接続を取得してトランザクションを管理するサービス層が必要です。

JDBC ドライバーの JAR と接続パラメーターを変更するだけで、データベースの切り替え (あったとしてもまれにしか発生しない) が簡単になるように、SQL を作成する必要があります。

于 2012-06-04T14:42:02.710 に答える
0

あなたが求めているのは、データ アクセス オブジェクト(DAO) パターンだと思います。Hibernateのようなオブジェクト リレーショナル マッピングのフレームワークを使用する場合、DAO は実際にデータベース スキーマを直接指定できます(これは非常に優れていると思います)。それ以外の場合は、基礎となるデータベースに関するすべての懸念を抽象化する一連の手動の DAO クラスを提供するのが一般的です (たとえば、DAO クラスは ResultSet を返すべきではありません)。

于 2012-06-04T14:43:30.977 に答える
0

すべてのエンティティに対してDAO クラス ( http://java.sun.com/blueprints/corej2eeppatterns/Patterns/DataAccessObject.html ) を作成することをお勧めします。これにより、SQL/HQL/内部が隠されます。それらはオブジェクトモデルを返すため、ビジネスロジッククラスはクエリ/データベースからのフェッチなどを気にしません。

于 2012-06-04T14:40:10.573 に答える
0

更新可能なデータベースと読み取り専用データベースの 2 つのアプローチで検索する必要があると思います。

データベースに何かを挿入/更新/削除したい場合、名前、データ型など、データベースがどのようになっているのかを知らなければ、これを達成する方法はないと思います...

しかし一方で、データベース内で検索したいだけの場合は、これを実現するための良い方法があります: データベース ビューを使用することです。多くのビューを持つことができ、この各ビューには必要なすべてのデータが含まれていますが、ビューの背後にあるデータを正確に知る必要はありません。元のテーブルではなくビューのみを表示するように一部のユーザーを制限できるため、実際のデータベース構造を「隠す」ことができます。

これは Java アプローチ以上のものだと思います。それはデータベース + Java アプローチです。

于 2012-06-04T14:45:02.037 に答える