java.sql.ResultSet、CallableStatement、SQLInput 没有通用接口

Question

情况是这样的

在jOOQ 中，非常需要对 JDBC 进行抽象。我希望 jOOQ 客户端代码不知道这样一个事实，即一些数据是从简单的 ResultSet 中检索的，一些数据是从 SQLInput（对于 UDT）或 CallableStatements（对于存储过程/函数）中检索的。因此，我想对这些 JDBC 类型添加抽象：

java.sql.ResultSet
java.sql.CallableStatement
java.sql.SQLInput
java.sql.SQLOutput

现在它们的工作方式几乎相同。对于java.sql.Types 中的每种数据类型，它们通常都有一个get 和set 方法。例如，他们提供了类似

的方法

BigDecimal getBigDecimal(int index);
int getInt(int index);

它们都有类似的方法

boolean wasNull();

问题

不幸的是，这些 JDBC 接口没有扩展单个通用接口，这让那些想要在这里编写像 sn-p 这样的通用 JDBC 代码的人的生活更轻松（只是一个支持我的问题的示例）：

// As JDBC has no support for BigInteger types directly,
// read a BigDecimal and transform it to a BigInteger
BigDecimal result = null;

if (source instanceof ResultSet) {
    result = ((ResultSet) source).getBigDecimal(index);
}
else if (source instanceof CallableStatement) {
    result = ((CallableStatement) source).getBigDecimal(index);
}
else if (source instanceof SQLInput) {
    result = ((SQLInput) source).readBigDecimal();
}

return result == null ? null : result.toBigInteger();

上面的代码需要为他们三个都写，ResultSet，CallableStatement，SQLInput。而且类似的例子还有很多

我的问题是

• 有人知道优雅地解决这个问题的 JDBC 扩展库吗？
• 或者我应该自己为所有这些类型编写一个简单的包装类（或适配器）？
• 或者您会接受这个事实并继续复制内部库代码？

您更喜欢哪种解决方案以及为什么？感谢您提供任何反馈

Answer 1

• 有人知道优雅地解决这个问题的 JDBC 扩展库吗？

不，必须有人发明它。

---

• 或者我应该自己为所有这些类型编写一个简单的包装类（或适配器）？

我肯定会去的。从一个通用的包装接口开始。

public interface DataProvider {
    public BigInteger getBigInteger(int columnIndex);
    // ...
}

让所有具体的包装器实现它。

public class ResultSetDataProvider implements DataProvider {
    private ResultSet resultSet;

    public ResultSetDataProvider(ResultSet resultSet) {
        this.resultSet = resultSet;
    }

    public BigInteger getBigInteger(int columnIndex) {
        BigDecimal bigDecimal = resultSet.getBigDecimal(columnIndex);
        return bigDecimal != null ? bigDecimal.toBigInteger() : null;
    }

    // ...
}

改用它。

try {
    // Acquire ResultSet.
    DataProvider dataProvider = new ResultSetDataProvider(resultSet);
    // Process DataProvider.
} finally {
    // Close ResultSet.
}

---

• 或者您会接受这个事实并继续复制内部库代码？

不，我不会。保留您的代码DRY。

Answer 2

就个人而言，我不会使用这样的东西。我没有看到你通过这种抽象让我的生活变得更轻松。

我认为 SQL 抽象没有理由从持久层中泄露出来。我进行调用、映射到对象并关闭 SQL 抽象。你听起来像是希望他们留下来，这是个坏主意。

我认为 Spring 的人们已经尽可能简单地使用 JDBC。我可能是错的，但我认为没有理由走你建议的道路。

如果我查看 SQLInput 的 javadocs，我会看到：

此接口，仅用于自定义 映射，由后面的驱动程序使用 场景，程序员永远不会 直接调用 SQLInput 方法。

我不确定您为什么认为有必要公开此接口。

对于 ResultSet 和 CallableStatement（或任何 Statement），它们最终可以返回一个或多个 ResultSet 以返回查询结果。我宁愿看到围绕它的抽象。我相信你暴露其他人是在搅浑水。我不会推荐它。

也许从未做过的事实是不应该做的另一个迹象。但是欢迎您这样做，看看市场是否会投票给您。

Answer 3

1. 不确定 JDBC 的扩展。
2. 包装类或访问者模式可能有用，具体取决于您设计的其余部分。
3. 如何扩展每一个并让它们实现具有相同方法签名的相同接口以获取所需数据。