首先，这个问题可能与Moving from hibernate to plain jdbc重复。
但既然那个问题没有得到我正在寻找的答案我又要问了。
假设我们有一个使用Hibernate的应用程序，我们决定将它全部改回JDBC查询。 （出于某种原因，Hibernate代码和依赖项将被完全删除）
这样做的逻辑方法是什么？ （按时间顺序逐步）
正如评论中指出的那样，这是非常依赖于应用程序的，但我将尝试编写一些我将采取的一般步骤：
1）为项目添加必要的依赖项（如果你想使用普通的JDBC，你可能已经在那里使用它们，但是如果你想使用一些额外的框架，这个步骤可能是必要的）。
2）确定应用程序中使用Hibernate的所有位置。
3）用JDBC预处理语句替换所有这些Hibernate查询。一个接一个地测试它是否有效。如果正确编写，则替换查询应更改应用程序的行为。您可能希望首先熟悉数据库结构以避免错误。
4）重写所有查询后，从应用程序中删除hibernate配置文件（*.hbm.xml）和依赖项。
5）再次测试一切正常。
我不知道你为什么要从Hibernate交换到JDBC。使用某些ORM框架有许多优点。您是否看过其他可能更适合您的框架？
例如，iBatis（或myBatis）允许您编写简化的SQL查询，并且它非常容易学习。
简短回答：没有意义。
答案很长：Hibernate是一个ORM，因此它将entity state transitions转换为SQL查询。像cascading，dirty checking这样的东西是由Hibernate处理的，所以切换到JDBC意味着你必须手动完成它。
使用ActiveRecord方法切换ORM是一项具有显着开发成本的架构决策。任何数据访问技术都是漏洞，因此您无法隔离数据访问代码，以便您可以轻松地交换任何技术。出于性能考虑，您必须设计数据模型和查询以充分利用数据库。
对于中型企业应用程序，无论如何您都需要特定于数据库的技术（例如CTE，窗口函数，LATERAL连接），因此无论如何您都需要本机SQL。
因此，最好的方法是同时使用Hibernate和SQL，而不是选择其中一个。
要回答你的问题：
您可以设计DAO接口，以便始终返回DTO，这意味着您有两个实现：
这样您将无法使用实体，因为JDBC DAO无法很好地获取实体树，因此您无论如何都需要手动执行。
使用Hibernate进行投影只会破坏使用ORM的全部意义，因此您可能首先会质疑您的架构决策。