混合使用Java和SQL查询时，如何做到最好？

作为我的

Java

程序的一部分，我需要对（

Oracle

）数据库执行大量查询

目前，我们混合使用SQL和Java，这（我知道）是一件坏事

处理这种事情的正确方法是什么？如果可能，请包括示例

多谢各位

编辑：

关于应用程序的更多信息。它是一个web应用程序，主要从数据库派生内容（它接受用户输入，并根据数据库认为正确的内容绘制下一步要查看的内容）

我现在最担心的是，当Java代码和SQL查询紧密结合时（查询硬编码为源代码的一部分），它们的混合看起来“不合适”

---

我正在寻找一种更干净的方法来处理这种情况，这将提高现有项目的可维护性和清晰度

您的问题似乎太笼统了，但是如果您在Oracle上混合使用了Direct SQL和Java SQL，那么最好在Hibernate或Apache Cayenne之类的ORM上投入一些时间。ORM是一种将数据库操作与Java端分离的独立设计方法。所有的数据库交互和数据库设计都是在ORM上实现的，所有的访问和业务逻辑都将驻留在Java中，这是一个建议。尽管你的实际问题还不清楚。

嗯，你可以考虑的一件事是（例如）。这将允许您将数据库模式映射到Java对象，这通常会清理Java代码

然而，如果性能和速度是关键，那么最好使用普通的JDBC驱动程序

当然，这也取决于应用程序试图完成的任务。例如，如果您需要基于CSV文件进行批量更新，我可能会选择纯JDBC解决方案。如果您正在设计一个web应用程序，我肯定会选择ORM解决方案

另外，请注意，纯JDBC解决方案需要在Java代码中包含SQL。实际上，就这一点而言，在任何ORM解决方案中都必须有某种形式的SQL，无论是它还是普通SQL。关键是，Java应用程序中的一些SQL并没有什么问题

编辑以响应OP的编辑

如果我从头开始编写web应用程序，我会使用ORM。然而，由于您已经有了一个工作的应用程序，从纯JDBC解决方案过渡到ORM将是非常痛苦的。它将清理您的代码，但这涉及到一个重要的学习曲线，并且需要相当多的设置。如果您使用某种bean管理系统，比如Spring，那么设置过程中的一些痛苦将会减轻，但它仍然非常重要

---

这还取决于您希望将应用程序带到哪里。如果您计划在相当长的一段时间内维护和添加此代码，重构可能是合适的。然而，我不建议仅仅因为您不喜欢在应用程序中硬编码SQL而重新编写您的系统。

基于您的更新，我同意Tim Pote关于“集成ORM的学习曲线”的编辑。但是，您可以不集成ORM，而是使用准备好的语句，然后将这些语句存储在属性文件中。甚至可以将查询存储在数据库中，这样您就可以对其进行细微的更新，然后可以在不重新启动应用程序服务器的情况下立即读取这些更新。这两种策略都会将硬编码SQL的Java代码分离

但最终，我不认为你的问题有一个明确的答案，因为你所做的没有本质上的错误。这只是有点僵化，但对于你的环境来说，也许是可以接受的

---

也就是说，我将此作为一个答案发布

Apache Cayenne是最容易使用的ORM之一。它附带了一个Cayenne Modeler来为数据对象建模并进行映射。对于ORM的初学者，我推荐Cayenne。它可以通过Modeler创建映射类和DB sync。

我不确定项目的状态，但您也可以找到一个名为MyBatis的“备用”对象关系映射器。它比流行的hibernate或eclipselink具有更低的学习曲线，让我们来实际编写查询，以便了解代码在做什么。如果ORM是你的事

我现在正在与JPA合作（主要是因为这是当前的趋势，需要学习）。JPA是ORM的Java标准。如果你想了解目前ORM的一种典型做事方式，JPA可能是最好的方式。像Hibernate和Eclipselink这样的框架驱动它。根据您选择的支持JPA应用程序的框架，您可以使用专有功能，但这将使您与该框架紧密相连。开始使用JPA并不难，但当它不起作用时，可能会非常神秘，因为它会混淆与数据库的交互（请注意，它确实允许使用本机SQL查询的选项，但这否定了人们说JPA风格的DB访问很好的原因）

是的，仍然有人使用JDBC编写语句。通常，在使用普通的JDBC编程时，您会使用一些实践/模式，这些实践/模式就像一个非常、非常简单的ORM。。。或者更接近MyBatis。同样，如果你走这条路，使用准备好的语句。它们消除了许多危险

---

这是一个宗教问题，所以你会听到很多关于你写问题的方式。事实上，有人可能会因此否决你的问题。我认为你唯一可以问的可能更糟糕的问题是，对于一群unix极客来说，emacs或vi是否更好。

对于你所描述的，合并对象关系映射器（ORM）或重写为存储过程可能比你想做的更多。博