別の初心者の質問。次のように宣言された Services という RDBMS テーブルがあります。
CREATE CACHED TABLE Services (
serv_id BIGINT GENERATED ALWAYS AS IDENTITY (START WITH 100) PRIMARY KEY,
enc_id BIGINT REFERENCES Encounters ( enc_id ),
prov_id INTEGER REFERENCES Providers ( prov_id ),
DoS DOUBLE DEFAULT 0.0 NOT NULL,
DoP DOUBLE DEFAULT 0.0 NOT NULL,
DoR DOUBLE DEFAULT 0.0 NOT NULL
);
このテーブルへのサービス オブジェクトの永続性を扱う場合、各 SQL フィールドを対応する Java タイプ フィールドにマップする Java クラスを作成しました。つまり、クラス サービスには同じ 6 つのフィールドがあります。JavaFX アプリケーションでこのテーブルを使用するアプリを開発しているため、各タイプに JavaFX プロパティ フィールドを使用しました。
Class Service {
LongProperty serv_id = new SimpleLongProperty();
:
}
ここで私が今気になっている問題...
私の RDBMS テーブルは高度に正規化されているため、このレベルで実際のデータベース テーブルを扱うことはほとんどありません。Services テーブルの情報をユーザーに提示する前に、次のクエリを実行します。
SELECT s.serv_id, r.rx_id, p.prov_id, s.*, sr.*, r.*,
p.lastName || ', ' || p.firstName AS provName" +
FROM Services AS s
INNER JOIN Service_RXs AS sr USING ( serv_id )
INNER JOIN RXCodes AS r USING ( rx_id )
INNER JOIN Providers AS p USING ( prov_id )
WHERE s.enc_id = ?
ORDER BY s.DoS DESC;
この結果セットには 11 列、つまり Services テーブルだけの列数の約 2 倍があります。この結果セットからの情報は、TableView に使用されます。TableView のデータ モデルを表すクラスを用意するのがベスト プラクティスであるため、次の 3 つの選択肢があるように思えます。
- 選択肢 1
1 つのクラスをすべての目的に使用できます。つまり、Service クラスを拡張して、永続層 (JDBC) と JavaFX GUI API の両方に必要な機能を表すことができます。私はこの解決策が嫌いです。つまり、オブジェクトの一部のみを永続化することについて心配する必要があり、非正規化されたすべてのデータを適切なタイミングで取得するためのメソッドが必要であり、自分のクラスについて考えるという魅力的な概念を省かなければならないということです。一つの役割として。
- 選択肢 2
1 つはデータベース テーブル用、もう 1 つは TableView のデータ モデル用に、完全に別個のクラスを作成できます。これで問題はないと思いますが、ある程度の重複の負担がかかるようにも見えます。
- 選択肢 3
Service クラス内に、対応する Service オブジェクトの非正規化形式を表す Service.Extended などの内部クラスを作成できます。一見すると、これは私にとって良い解決策のように思えます。オブジェクト間の目的の分離を維持することができます。内部クラスのオブジェクトは、囲んでいるクラスの必要なフィールドにもアクセスできるため、重複を回避できます。コード内で新しい Service.Extended オブジェクトをきれいに作成する静的ファクトリ メソッドを使用して、ObservableList の JavaFX データ モデル オブジェクトを簡単に作成できると思います。
私はこの同じ問題を抱えた最初の人になることはできません. 正規化されたデータ セットを GUI プレゼンテーション レイヤーに適応させようとしたときに他の人が採用したソリューションは何ですか? これは、Hibernate/JPA が支援するようなものですか? JDBC に固執する場合、内部クラスのアプローチは良い考えですか?