普通Java持久性和JavaFX表示层：类设计方法？

另一个新手问题。我有一个名为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
);

在处理该表中服务对象的持久性时，我编写了一个Java类，它将每个SQL字段映射到相应的Java类型字段中，也就是说，该类服务具有相同的六个字段。因为我正在开发一个在JavaFX应用程序中使用此表的应用程序，所以我为每种类型使用了JavaFX属性字段，例如

Class Service {
    LongProperty serv_id = new SimpleLongProperty();
    :
}

这是我现在想知道的问题

我的RDBMS表是高度规范化的，所以我几乎从不在这个级别处理实际的数据库表。在向用户显示我的服务表中的信息之前，我执行以下查询：

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表中列数的两倍。此结果集中的信息用于TableView。因为拥有一个表示TableView数据模型的类是最佳实践，所以在我看来，我有三个选择：

• 选择1

我可以将一个类用于所有目的，也就是说，我可以扩展服务类来表示我的持久性层（即JDBC）和JavaFXGUI API所需的功能。我不喜欢这种解决办法。这意味着我必须担心只保留对象的一部分，我必须有方法在正确的时间获取所有非规范化数据，我必须放弃将类看作只有一个角色的想法

• 选择2

我可以编写完全独立的类，一个用于数据库表，另一个用于TableView的数据模型。我不认为这有什么错，但它似乎也会带来一定数量的重复负担

• 选择3

我可以在服务类中编写一个内部类，比如Service.Extended，它将表示相应服务对象的非规范化形式。乍一看，这对我来说是个不错的解决办法。它允许我保持对象之间的目的分离。内部类对象还可以访问封闭类中所需的字段，从而避免重复。我设想，我可以使用静态工厂方法轻松地为ObservableList创建JavaFX数据模型对象，该方法将在代码中干净地创建新的Service.Extended对象

---

我不可能是第一个有同样问题的人。如果我可能会问，其他人在尝试将规范化数据集调整到GUI表示层时采用了哪些解决方案？这是Hibernate/JPA帮助解决的问题吗？如果我坚持使用JDBC，那么内部类方法是一个好主意吗？

从UI返回如何？我的意思是：

• 设计用户界面来完成您需要它做的事情
• 在中使用JavaFX属性创建一个支持类（模型）
• 编写DAO以在表中存储模型的属性

通过这样做，您只编写了您真正需要的代码，而不需要担心抽象。尽管DAO将反映数据库设计的复杂性，以1:1的比例解决您试图解决的问题

最好、最简单的解决方案是最直接的，代码最少，类最少，第三方依赖性最少

还要记住，在后台线程中运行数据库操作是体系结构的关键部分。不应从其他线程访问JavaFX属性。试图改造这个对我来说真的很痛苦