为什么我们使用DataSource而不是DriverManager？

Question

我正在阅读Java JDBC规范(vr.4),并且我对此声明进行了说明:

DataSource - 此接口是在JDBC 2.0 Optional Package API中引入的.它优先于DriverManager,因为它允许有关底层数据源的详细信息对应用程序透明

我想要了解的是a Connection和a 之间的差异DataSource,以及它存在的原因.我的意思是,上面的块表示有关数据源的详细信息对应用程序是透明的,但是不会在属性文件中外部化数据库属性(如用户名,密码,URL等),然后以相同的方式使用DriverManager工作？

DataSource创建的界面是否只有一种通用的方式来返回可以合并的连接？在Java EE中,应用程序服务器是否实现此接口,并且部署的应用程序是否具有对数据源而不是连接的引用？

Answer 1

更好的可扩展性和维护

对于驱动程序管理器,您需要知道连接到数据库和获取连接的所有详细信息(主机,端口,用户名,密码,驱动程序类).将属性文件中的内容外部化并不会改变您需要了解它们的任何事实.

使用DataSource,您只需要知道JNDI名称.AppServer关注详细信息,并不是由客户端应用程序的供应商配置,而是由托管应用程序的管理员配置.

可扩展性:

假设您需要自己创建连接,如何处理更改负载,有时当您有1000个用户时有10个用户,您不能只在需要时获得连接,然后"释放"它以便数据库服务器不会脱离连接,导致连接池.DriverManager不提供它,DataSource也提供它.

如果要编写连接池,则必须使用DriverManager,否则请使用DataSource.

Answer 2

DriverManager的.

• 在java类中创建/关闭连接时会妨碍应用程序性能.
• 不支持连接池.

数据源

• 由于不在类中创建/关闭连接,因此它们可以提高应用程序性能,它们由应用程序服务器管理,并且可以在运行时获取.
• 它提供了一个创建连接池的工具
• 有助于企业应用程序

Answer 3

太长了；博士

\n

\n
• DataSource是一种外部化连接到数据库服务器所需信息的方法：服务器名称或地址、用户名、用户密码、特定于特定数据库引擎的设置等。
\n
• DriverManager在你最初的学习过程中没问题。但是，在部署到生产环境时，您\xe2\x80\x99 不希望在代码库中硬编码连接信息。在实际工作中，使用DataSource而不是DriverManager访问外部化的配置信息（地址、名称、密码等）。
\n
• Connection是您与数据库的实时连接。对象DataSource将使用 aDriverManager来获取一个Connection对象，供您在查询数据库时使用。
\n

\n

细节

\n

让我们看看您问题的具体情况。

\n

\n

Connection我想了解的是 a和 a之间的区别DataSource

\n

\n

对象Connection代表与数据库服务器的实时会话，来回进行查询并获取结果。

\n

对象DataSource保存连接数据库所需的凭据。通常，aDataSource保存数据库服务器识别的用户名、该用户的密码以及用于自定义未来与数据库的任何会话的各种设置。ADataSource不是“开”或“闭”；Connection它仅保存打开或关闭所需的信息。

\n

\n

为什么它存在

\n

\n

Connection作为与数据库服务器对话的管道而存在。

\n

DataSource存在是为了避免在 app\xe2\x80\x99s 代码库中硬编码连接信息（用户名、密码、选项）。在实际工作中，部署应用程序后，您\xe2\x80\x99 不希望仅仅因为DBA轮换密码而编辑代码、重新编译和重新部署。

\n

作为一名程序员，您不希望受到数据库服务器\xe2\x80\x99s机器网络地址、用户名、用户密码等部署问题的影响。您\xe2\x80\x99将希望该信息在代码库之外外部化。

\n

\n

在属性文件中外部化数据库属性，例如用户名、密码、url 等，然后使用 DriverManager 以相同的方式工作？

\n

\n

不会。您的代码仍将被硬编码以查找该属性文件。但 DBA 和系统管理员还有其他方法来配置和传达连接信息（用户名、密码、服务器地址等）。Java 程序员不应该对部署期间要进行的选择和更改做出假设。

\n

将该信息外部化的主要方法是将信息放置在目录服务器中。有许多目录服务器实现。这些通常通过标准化接口（例如LDAP接口）进行访问。

\n

Java 为基于 Java 的应用程序提供了一种通过标准化接口与目录服务交互的工具。该工具称为 Java 命名和目录接口 (JNDI)。

\n

通过 JNDI，您的应用程序可以要求目录服务提供包含必要连接信息的DataSource对象。通过使用 JNDI，您的应用程序无需假设 DBA/系统管理员选择如何将此连接信息传递给您的应用程序。事实上，作为一名程序员，您不需要了解他们的部署选择和更改。

\n

\n

DataSource创建接口只是为了有一种返回可以池化等连接的通用方式吗？

\n

\n

调用返回的连接DataSource#getConnection可能是也可能不是连接池的一部分。作为 Java 程序员，您通常不会关心。在部署时，DBA/系统管理员可能最初使用非池连接进行部署。然后他们可能会更改为使用池连接。同样，您无需关心，也无需编辑代码、重新编译和重新部署。DBA 可以在无需您参与的情况下更改池。

\n

\n

在 Java EE 中，应用程序服务器是否实现此接口，并且部署的应用程序是否具有对数据源而不是连接的引用？

\n

\n

仅供参考，在Oracle 公司将责任转移给Eclipse 基金会后，Java EE 现在被称为Jakarta EE。

\n

您可以在任何类型的 Java 应用程序中使用JDBC和对象：控制台、桌面（JavaFX / Swing / SWT）、Web 应用程序、微服务等。DataSource

\n

通过“此接口”，如果您的意思是接口\xe2\x80\xa6不DataSource，Jakarta EE 实现（例如Tomcat、Jetty、Glassfish、Payara、WildFly、JBoss、Open Liberty）不实现。通常，JDBC 驱动程序会提供实现，或者您的连接池实现会提供实现。DataSource

\n

同样，这是由 DBA/系统管理员在部署时配置的，而不是在开发期间由程序员配置的。您不应将JDBC 驱动程序与 Jakarta EE 应用程序捆绑在一起。相反，配置您的依赖项管理器（Maven、Gradle 等）以使驱动程序仅在您的工作开发期间暂时可用，而不是在用于.war部署的最终工件（文件等）中。

\n

Jakarta EE 实现负责为您的应用程序获取DataSource对象。该实现本身可以充当目录服务；例如，Tomcat 可以将连接信息保存在其自己的配置文件中，然后将该信息作为DataSource对象传递给您的应用程序。或者，DBA/系统管理员可以将 Jakarta EE 实现配置为连接到单独的目录服务器实现，例如Microsoft Active Directory或OpenLDAP。再次强调，作为 Java 程序员，所有这些细节都与您无关。

\n

\n

部署的应用程序引用数据源而不是连接？

\n

\n

在 Jakarta EE 部署中，Jakarta EE 实现DataSource向您的应用程序提供一个对象。getConnection然后，您的应用程序代码在需要与数据库服务器通信时调用。Connection然后，您的应用程序代码在与数据库服务器通信完成后关闭生成的对象。

\n

提示：使用 try-with-resources 语法自动关闭连接、语句和其他 JDBC 资源。如上所述，从DataSource这个意义上讲，对象不是资源，并且本身永远不会打开或关闭。

\n

Answer 4

DataSourceDataSource对象可以提供连接池和分布式事务，因此如果您需要其中一项或两项功能，则可能必须使用。