1

私は、単一サーバー データベースを中心に構築された JDBC アプリケーションを持っています (RDBMS は HSQLDB で、これまでのところ気に入っています)。アプリケーションの最初のドラフトでは、次の段階的アプローチを使用しました。

+-------------------------------+ 
|  DATA STORE (appx 20 tables)  |  HSQLDB; highly normalized tables
+-------------------------------+
                |
                v
+-------------------------------+
|  DOMAIN OBJECT LAYER  (1:1)   |  A Java class for each table in DB
+-------------------------------+
                |
                v
+-------------------------------+  Abstraction for the objects that the app
|  CLIENT OBJECT LAYER / DAO's  |  logic actually uses (denormalized)
+-------------------------------+
                |
                V
+-------------------------------+  Adapts ObservableArrayList() instances 
|  PRESENTATION LAYER (JAVAFX)  |  of objects to the GUI
+-------------------------------+

ドメイン オブジェクト レイヤーでは、現在、すべての JDBC クエリを一般的な静的メソッドで実行しています。

static <E> ObservableList<E> doGenericQuery(SQLParametersList pars,
        String sql, Callback<RowSet,E> factory) {

    // factory is a Function Object. For now I use Callback<P,R> as the
    // "strategy" ... P is a RowSet, R is the object return type. The factory
    // simply invokes the constructor for the desired return object type.


    RowSet jrs = null;
    ObservableList<E> queryList = FXCollections.<E>observableArrayList();

    try {
        jrs = SQLConnection.getRowSetInstance();
        if (jrs == null) {
            System.err.println(Census.MSG_ERR_JDBCFAIL);
            return queryList; }

        jrs.setCommand(sql);

        for(int i=0; i < pars.size(); i++) {

            // datum().col() method returns an enum representing the
            // database column; setJdbcParamByType is an enum 
            // constant-specific method that invokes the correct
            // setXXX method on the PreparedStatement

            pars.datum(i).col().setJdbcParamByType(jrs, pars.datum(i)));
        }

        jrs.execute();

        while (jrs.next()) {
            queryList.add(factory.<RowSet,E>call(jrs));
        }

    } catch (SQLException e) {            
        Logger.getLogger(DB.class.getName()).log(Level.SEVERE, null, e);

    } finally {            
        if (jrs != null) try { jrs.close(); } catch (SQLException e) { }
    }

    return queryList; 
}

私がやりたいことは、アプリケーション全体のデータ アクセスの抽象化でこのメソッドを使用することですが、できるかどうか疑問に思っています。書かれているように、このメソッドは ObservableList を返します。これは、JavaFX アプリケーションによって使用されるためです。ObservableList は、SimpleXXXProperty オブジェクト (JavaFX Bean スタイル、つまり変更可能なオブジェクト) のインスタンスを保持します。JavaFX Bean スタイルのオブジェクトをサーバー側に持ちたくないので、現在書かれているこのコードを使用できるとは思いません。

最終的に、データ アクセス レイヤーはサーバー側環境で実行され、プレゼンテーション レイヤーはクライアント側で実行されます。

サーバー側のコードで JavaFX Bean スタイルのオブジェクトを使用したくありません。理想的には、クエリが不変オブジェクトのリストを形成することを望んでおり、すべてを公開して変更可能にすることを義務付けているように見える JavaFX を処理する必要性を除いて、それを達成できると思います。

私が今考えている解決策は、サーバー コードでクエリ結果から不変オブジェクトを作成し、それを unmodifiableList にラップしてクライアントに送信することです。次にクライアントは、読み取り専用リストを JavaFX Bean スタイルのオブジェクトの ObservableList に変換して、GUI で使用できるようにする必要があります。しかし .. このアプローチでは、異なるバージョンのドメイン オブジェクト レイヤー (クライアントとサーバー) を作成する必要があります。

私はここで正しい軌道に乗っていますか?(ここで、私が頭を抱えているように聞こえるのは嫌いです..しかし、私は今頭を抱えているかもしれません)。

4

1 に答える 1

0

自分がやりたいことは何なのかを考えていくうちに、自分のアプローチが単純すぎることに気づきました。私が実際に話していると思うのは、データ ストアからクライアントへの情報の流れで、次のようになります。

+-------------------------------+ 
|  DATA STORE (appx 20 tables)  |  HSQLDB; highly normalized tables
+-------------------------------+
                |
                v
+-------------------------------+  Receives query result
|  SERVER/SERVLET REQ PROCESSOR |  Transmits as CachedRowSet
+-------------------------------+
                |
         (Serialization)
                |
                v
+-------------------------------+
|     CLIENT INTERFACE LAYER    |  Deserializes query results
+-------------------------------+
                |
                v
+-------------------------------+
|  DOMAIN OBJECT LAYER  (1:1)   |  A Java class for each table in DB
+-------------------------------+  Generates data model objects from results
                |
                v
+-------------------------------+  Abstraction for the objects that the app
|  CLIENT OBJECT LAYER / DAO's  |  logic actually uses (denormalized)
+-------------------------------+
                |
                V
+-------------------------------+  Adapts ObservableArrayList() instances 
|  PRESENTATION LAYER (JAVAFX)  |  of objects to the GUI
+-------------------------------+

もちろん、これは現在、フレームワークが既に存在するインターネットベースのクライアントサーバーアプリのように見えます。JavaEE。シンプルな単一マシンの JDBC データベース アプリから分散型クライアント サーバー アプリに移行するには、複雑さが飛躍的に向上するようです。

しかし、クライアントを除いて、このプロセスのどこでも JavaFX Bean スタイルのオブジェクトを使用する必要があるとはまったく思いません。

于 2013-08-13T16:29:45.703 に答える