从Java执行查询时，哪种方法更好

我有以下疑问。当您必须从Java应用程序查询数据库时，有几种方法可以做到这一点。我想出了一些方法，但每种方法都有一个缺点

第一个是，您有一个类，例如

QueryManager

，它为您提供查询功能，如

executeUpdate（…）

和

executeQuery（…）

，同时隐藏连接管理的详细信息等（类似于一种查询）。当您需要与数据库交互时，您将以字符串形式传递查询并管理

结果集

我看到的问题是，如果数据库发生变化，无论是DBMS还是DB本身，最终都会逐个文件修改SQL。我认为这是一个巨大的依赖。此外，您还向所有人公开了数据库的结构，并让每个类处理

结果集。另一方面，通过使用这种方法，您可以获得更高的模块性，因为类的模型（我非常喜欢）可以具有包可见性

我想到的第二个想法是创建一个
QueryManager
类，它不提供查询方法，而是提供所需的方法。换句话说，每次需要使用DB时，您都会在这个类中创建一个方法，其中包含SQL，该方法将返回您需要的信息。但是，我们在这里面临的问题是，您必须在返回
结果集
或所需数据模型之间进行选择。

前者将使您的类依赖于数据库，这比上一个示例中要少，因为现在DBMS没有广泛的依赖关系，因为所有SQL都包含在一个类/文件中。但是，它仍然存在与数据库结构的依赖关系，并且您正在向所有人公开您的数据库结构。

后者意味着SE模型不再是包可见性，它们必须是公共的，允许任何类修改它们，并破坏封装

有没有其他方法可以解决之前的所有问题？如果不是，您认为哪种方法更好

我不认为有绝对的答案（也许有），但我必须说，我们期待着数据库和数据库管理系统的结构都会发生变化。这可能有助于你的穿着。但是尽量使它更一般，因为我可能在其他项目中有同样的疑问，但没有相同的限制。
我建议为所有实体创建DAO类（），这将隐藏SQL/HQL/内部的任何内容。它们将返回对象模型，因此业务逻辑类将不关心查询/从数据库获取等。
我不喜欢这两种方法

您可以编写一个单独的接口来处理所有这些：泛型DAO。下面是一个简单的示例，并不打算作为完整的答案，因为它不允许临时查询或映射到任意对象，但这只是一个开始：

public interface GenericDao<K, V> {
    List<V> find();
    V find(K key);
    K save(V value);
    void update(V value);
    void delete(V value);
}

公共接口GenericDao{
列表查找（）；
V查找（K键）；
K保存（V值）；
无效更新（V值）；
无效删除（V值）；
}

您应该在持久性和模型类之间有一个清晰的接口；后者不必知道前者

您不应该允许
ResultSet
或
语句
泄漏出持久层

您应该有一个获取连接和管理事务的服务层

在编写SQL时，切换数据库（如果有的话，这种情况应该很少发生）就像更改JDBC驱动程序JAR和连接参数一样简单。
我认为您所追求的是（DAO）模式。如果您使用一个对象关系映射框架，比如，DAO实际上可以（我认为这是非常整洁的）。否则，通常会提供一组手动编译的DAO类，这些类会抽象掉所有底层数据库关注点（例如，DAO类不应返回ResultSet）。
第二个是好的：您应该在数据访问对象（DAO）中提取数据访问方法，它将应用程序的其余部分与持久性相关的问题隔离开来。DAO应该返回对象，而不是结果集

这具有以下优点：


关切和责任的脱钩
当模式更改时，应用程序的其余部分更容易演化
当您选择使用ORM而不是JDBC来访问数据库时，应用程序的其余部分将更容易演化
更容易的查询单元测试（以及通常的持久层测试），因为持久性代码没有与函数代码混合
更容易对业务（服务）层进行单元测试，因为它允许注入模拟DAO来提供数据，而不需要数据库中的真实数据来测试数据
我认为我们必须使用两种方法进行查找：可更新数据库和只读数据库

如果你想在你的数据库中插入/更新/删除一些东西，我认为如果你不知道你的数据库是怎样的：名称，数据类型

但是，另一方面，如果您只想搜索数据库，有一种很好的方法可以实现这一点：使用数据库视图。你可以有很多视图，每个视图都有你需要的所有数据，但是没有人需要知道视图背后到底有哪些数据。可以限制某些用户只查看视图，而不查看原始表，因此可以“隐藏”真实的数据库结构

我认为这不仅仅是Java方法：它是一种数据库+Java方法。
您是否考虑过使用Hibernate之类的对象关系映射器或其他实现JPA标准的方法？您可以使用它来管理所有这些问题。在实际应用中，您需要执行查询，而不是获取表中的所有行。我不明白这是怎么回事