Java 设计：将JDBC和数据源抽象为SQL/DefaultTableModel

我的后端调用动态数据源和拓扑，而我的前端调用一组查询RDBMS的应用程序编码。我的想法是完全脱离JDBCAPI，因为事实证明，对于应用程序编码本身耦合到的任何API

以下是设计理念。。。在查询时，应用程序代码传入SQL，并作为结果接收DefaultTableModel。更新时，应用程序代码传入SQL（甚至是一批），并因此接收成功/失败代码（加上错误消息）

你会将所有的应用程序代码耦合到类DefaultTableModel吗？是否有更好的类用于通用的、解耦的查询结果处理？（如果我需要元数据，我可以用结果对其进行子类化/封装）有没有这样的例子？我不需要超过以上的申请。我没有过度的RDBMS需求

---

Java API有哪些标准的非JDBC选项来保存ResultSet中的数据类型？我知道AbstractTableModel和DefaultTableModel。在任何情况下，它都必须足够聪明，能够根据数据类型将一个类与每个列相关联

JTable

是一个图形组件。返回数据是一个奇怪的选择。如果（前端）应用程序能够感知SQL，而后端能够返回

JTables

，这似乎是倒退。你能进一步阐明你的意图吗？什么东西比JTable图形化程度低？哦，也许是我的模特。Mick，前端支持表和列，也可以支持SQL。我不认为有必要（在本例中）让它了解JDBC，我不确定我是否理解这个问题。正确的设计要求前端不关心后端（反之亦然），而是接收格式良好的数据。这可以是实际的域对象，也可以是一些常规的

集合

类型（如果未键入数据）。在任何地方传递SQL都不是一个好主意。但是表不是在域级别吗？毕竟，SQL是第四代GL。但不是JDBC。