面向对象还是面向数据

最新推荐文章于 2021-10-08 22:13:19 发布

dongpoyezi

最新推荐文章于 2021-10-08 22:13:19 发布

阅读量490

点赞数

分类专栏： j2ee 文章标签： SQL OO ORM 项目管理

j2ee 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

做过一些j2ee的项目,用过不同的方式,但是还是有一些困惑,实际上我想很多人都有或者曾有过这样的困惑,有困惑的人大家一起讨论下,过来人也希望能指点下.我暂且称之为面向对象和面向数据的方式.

1)面向对象方式:一个典型的j2ee系统一般分为页面,后台,以及数据库.在很多情况下都是根据需求先去设计数据库,那么在根据数据库来设计对象(pojo),在pojo中维护数据库表之间的关系.最后把这些对象在页面上展现出来.当然这只是很简单的情况,这样做出来能够满足OO的思想,从数据库到后台再到页面对象是基本一致的.程序也比较清楚.我称这种方式为面向对象方式.使用这种方式一般都要借助ORM工具.

但是很多人都知道这样做有个缺点,就是有潜在的性能问题.举个简单的例子,我在数据库有三张表,典型的权限管理.USER,ROLE,和中间表USER_PROLE.

同样在程序中我该有个User和Role的pojo,User里面包含一个Set的属性,role 象这样:

    Java代码  
  
        public class User {  
  
    private String userName;  
      
        private String passWord;  
      
        private Wife  wife;  
  
        private Set<Role> roles;  
          
       ..........................  
  
}

1对多的情况:如果正好是页面上让我展现一些用户,并且显示这些用户对应的角色,那么很简单,ORM工具会在取出User的同时把roles也取出来.这个时候就会产生传说中的n+1的问题,但是实际上呢,如果你数据量不是特别大的话,你sql也会这么写.除非你采取存储过程,或者缓存的方式来规避这个问题.

1对1的情况:如果User 和另一个pojo是一对一的情况.比如wife.这个pojo里有user老婆的信息.在数据库中也有个WIFE的表对应.如果我有个查询是user的一些信息和wife的一些信息的组合.那么ORM工具会怎么做呢,一般会先

select USER_KEY, USERNAME ,PASSWORD,....... from USER

然后根据每个user 再:

select WIFENAME,......from WIFE where USER_KEY =?

user 一多,这条语句会产生很多次,如果我直接用sql来查的话就很简单,一句就够了:

select a.USER_KEY, a.USERNAME ,a.PASSWORD,b.WIFENAME....... from USER a, WIFE b

where a.USER_KEY=b.USER_KEY

这样IO的消耗明显降低,但是问题出来了,我返回的数据现在并没有一个pojo能满足.我是新建一个pojo吗,这个pojo同时有有查询出来的所有字段的对应属性,或者我是直接返回一个包含map的list? 两种方法都不太好,都破坏了设计.

在来考虑下更复杂的情况,比如说有4,5个表连接在一起,然后在程序中有4.5个pojo互相关联,我如果用ORM,想想会产生多少sql,我用sql语句,一个关联就可以.当然也会有人说,你这样做关联,实际上在数据库端效率也很低.你用ORM表面上会有很多sql语句,但其实数据库有缓存的 ,效率没有你想象的那么低,也许这也是有一定的道理的.但我数据库不精通,我怎么知道他是命中了缓存呢,或者我怎么能提高这些sql的命中率呢?

2)面向数据的方式这种方式实际上是以页面为驱动来设计,页面上有多少个字段我对应的javaBean(DTO)就应该有多少个字段.数据库与DTO的不一致通过sql来弥补.

就向上面同样的需求我有个查询是user的一些信息和wife的一些信息的组合,那么我DTO会这样写:

 public class User {

       private String userName;  
  
       private String passWord;  
  
       private String wifeName;  
  
       private String roleName;  
         
      ..........................  
}

因为这时以页面开始驱动的,所以,最后结果可能就是一个功能对应一个DTO.不可避免会有很多重复的字段.很不OO,但这块实际上并不是那么难以维护的,每个人维护自己功能的DTO.比较难以维护的是sql语句.为了解决后台数据库与前台页面的不一致很可能写出很复杂的sql语句.

在效率上,如果sql写的得当,效率会比较高,但写的不得当,效率很低,甚至比第一种方法中一大串的sql更慢.

那么到底哪种方式好呢,我现在觉得要看情况,如果页面的设计能和后台的数据库设计保持一定的一致,那么实际上后台的设计可以更OO.那么第一种方法好些,如果有些功能的数据量特别大,可以在这些功能用第二种方式.

但是实际很多项目页面设计是一些人,数据库设计是另一些人,那如果你作为程序后台的设计,我觉得用第二种稍好些.应为页面上要显示的东西和后台的数据库很不一致,你经常要糅合几张表的关系.那么你要在后台来糅合这种关系很困难,所以通过sql来糅合这种不一致也许是稍好些的方法.