我假设您实际上拥有一个比 DTO 更丰富的对象模型，而不仅仅是与您的关系模式 1:1 的对应关系。如果没有，你就不会赢得争论。
如果 Hibernate 生成的 SQL 至少与存储过程中的手工编码内容一样有效，那么您就赢了。
如果可以优化存储的 proc 以比 Hiberate 生成的 SQL 执行得更好，那么您就输了。
如果数据库由依赖存储过程的其他应用程序共享，则您会失败。您无法轻松地将逻辑移至 Spring 和中间层。
如果您的应用拥有数据库，则情况会更好。
由于您已经在使用 Spring，这表明您有一个利用 Spring Validation 的 DAO 层。PreparedStatements 已经在下面使用了，所以 SQL 注入对于 Spring 和存储过程来说都是不可能的。
那么如何以及说什么/呈现/解释/争论来至少改变他们对 ORM 的态度呢？
询问他们是否想要继续为您添加到应用程序中的每个新实体类型编写相同的样板 SQL JDBC CRUD 代码。
如果数据层中没有 ORM 解决方案，每个新实体类都需要 N 个工作单元才能使该实体通过数据层可用（DAO、CRUD 代码、存储过程、编写查询等）。
ORM 将该 N 转换为其自身的一部分，假设添加新实体只需要您在元数据中为该实体添加另一个映射。
| 归档时间： |
|
| 查看次数： |
6102 次 |
| 最近记录： |