JPA与JDBC,存储过程和公司,或者如何说服老派程序员尝试ORM?

如果数据库由依赖于存储过程的其他应用程序共享,则会失败。你不能轻易地把逻辑转移到Spring和中间层。

如果你的应用拥有数据库,你会有更好的情况。

存储过程是一个抽象层。JPA要求您了解底层表结构。存储过程/函数掩盖了这一点;您只需要知道要调用的过程或函数及其返回类型。

prepareCall 方法。

存储过程还添加了一层安全性:应用程序本身通常不能手动修改表,只能调用进行修改的过程。SP/SF还应该验证传递给它的参数。

存储过程的主要缺点是获取数据。。。您需要创建自己的工具来映射返回到Java对象的数组和结构,通常使用 type Map SQLData 接口。

那么,如何和怎样说/提出/解释/争论,至少能改变他们对ORM的态度?

询问他们是否希望为您添加到应用程序中的每个新实体类型继续编写相同的样板sqljdbc CRUD代码。

在数据层中没有ORM解决方案,每个新的实体类都需要N个工作单元才能使该实体在数据层中可用(dao、CRUD代码、存储过程、编写查询等)。

ORM将N转换为它自身的一部分,假设添加新实体需要您在元数据中为该实体添加另一个映射。

更少的样板文件和额外的安全性。你可以省去你的手指和初级程序员很少有机会引入SQL注入漏洞,我认为这是非常重要的。

我想 this answer 从你的相关问题链接解决潜在的问题。如果数据库的用途与您的应用程序紧密耦合,并且它实际上没有单独的标识,那么ORM就非常有意义。

但是,如果您的数据库代表了一个更大的画面,并且您的应用程序是访问数据的众多应用程序之一,那么使用ORM可能会对应用程序和数据库之间的耦合以及随着时间的推移更改数据库的需要产生潜在的负面影响。

您的问题的答案实际上非常简单,完全独立于您是否是一个死忠DBA。你必须扪心自问:

您是否正在编写一个以领域模型为中心的应用程序,其中包含大量CRUD?

或者,您是在编写一个以关系模型为中心的应用程序,而没有那么多CRUD?

在第一种情况下,选择一个ORM。在第二种情况下,选择SQL。如果您的应用程序中同时有这两个选项,请同时选择这两个选项。虽然ORMs和ORMs并不是互斥的 做 在你的应用程序设计上强加了很多规则。

“下一件事” 在Java世界里。他们是一个伟大的发明,只有解决 一些

ORMs使应用程序出错的机会减少一半,而存储过程出错的机会增加了一倍。

另外,如何单独测试SPs?

记住,代码中的一个bug和数据库中的一个bug可以很好地结合起来创建一个有效的解决方案。就像数学中两个负数变成正数一样。当SP被修复而不修复代码时,它就会变得混乱,反之亦然。