面向对象还是面向数据

做过一些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会这样写:             Java代码
public class User {

       private String userName;

       private String passWord;

       private String wifeName;

       private String roleName;

      ..........................
}   public class User {       private String userName;

       private String passWord;

       private String wifeName;

       private String roleName;

      ..........................
}         因为这时以页面开始驱动的,所以,最后结果可能就是一个功能对应一个DTO.不可避免会有很多重复的字段.很不OO,但这块实际上并不是那么难以维护的,每个人维护自己功能的DTO.比较难以维护的是sql语句.为了解决后台数据库与前台页面的不一致很可能写出很复杂的sql语句.      在效率上,如果sql写的得当,效率会比较高,但写的不得当,效率很低,甚至比第一种方法中一大串的sql更慢.         那么到底哪种方式好呢,我现在觉得要看情况,如果页面的设计能和后台的数据库设计保持一定的一致,那么实际上后台的设计可以更OO.那么第一种方法好些,如果有些功能的数据量特别大,可以在这些功能用第二种方式.     但是实际很多项目页面设计是一些人,数据库设计是另一些人,那如果你作为程序后台的设计,我觉得用第二种稍好些.应为页面上要显示的东西和后台的数据库很不一致,你经常要糅合几张表的关系.那么你要在后台来糅合这种关系很困难,所以通过sql来糅合这种不一致也许是稍好些的方法.     大家讨论下。

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

现在还没面向对象的数据库,其实很多软件系统说到底就是数据库表的操作界面，如果数据库是面向对象的话，那现在很多技术就OVER了
连最牛的ORACLE都是关系型的哦
LZ的困惑可以看看Spring关于Bean注入
实际上，有一定规模的项目，至少都是四帮人来做的：
1 最顶层的架构设计人员
2 服务端开发人员（包括了业务开发人员）
3 前台开发人员（包括了UI设计人员）
4 数据库相关人员但现实中，很多小公司、小项目，其实都是靠很少的几个人集中精力来完成。
所以，这样的项目谈不上架构，只是按照很多大家习惯的方式去做而已。LZ所谓的两种方式，无非是从后向前与从前向后的区别，也可以认为是数据驱动与业务驱动的区别。但这些分类并不完全等同，仅仅是类似。选择何种解决思路取决你的业务问题，取决于你的项目类型。或者说，这是架构设计人员的事情。
一个系统的性能瓶颈可能会有很多处，但只要大家在各自的环节都做到按需索取等基本的原则，在你现有的框架或者说架构下，其实已经可以解决问题了。如果你非要做缓存和优化，那么相信在开发之前就已经有人考虑到这些并且做了相应的设计。
楼主的这个帖子很精彩。但我并不认为这两种方式是互斥的，我觉得他们是互补的，
可以用来解决不同类型的问题。界面上经常出现“总-分”模式，就是先看列表，然后从列表再看某一项的详细信息，
列表往往来自多表关联的结果，更适合采用你说的”数据驱动“，直接为特定的SQL查询设计DTO，
而详细信息页面往往是一个对象入口，用1-N的关系检索出相关信息（就像你说的用户-角色），
那么用你说的”对象驱动“模式更合适。手段本身没有优劣之分，就看用的是不是恰当，
即便从数据库开始设计，作出对应的java类，也不影响再进一步封装不和表对应的DTO。楼主认为呢？
你的项目怎么总是想着用hql呢？如果性能有问题，自己写sql，还有，不是有延迟加载吗？楼主思想之所以困惑是因为走了极端，面向对象并不是说一切都必须oo才可以，具体问题具体分析，首先要把握问题的重点，再决定怎么做，没有问题，就想要问解决方法，是不可取的，推荐你看一下你的灯亮着吗这本书。楼主是思想的困惑，不是技术的疑问。
面向对象的思想发展与C/S结构的基于数据库的软件架构，对象在客户端和服务器创建之后可以一直使用重复利用，所以C/S模式可以充分利用其优点，分散其缺点但对于大规模用户访问的b/s结构不同，客户端不能创建对象，对象全部在服务器端创建，如果不平凡销毁再创建，
那么对于访问量大的系统内存需求却是难以估量，平凡销毁再创建同样是一个灾难所以，没看过门户，社交类网站会用面向对象来设计面向对象的B/S还是适合小型的（员工数量低、没有分公司）企业服务软件的面向数据对开发人员要求较高，web， server，datebase都需要精通，全能型的不管如何，没有哪种架构是绝对使用于的，需要综合考虑
学习了。
做了4年web开发，到现在用的还完全和oo没有关系。
正要学习框架方面的知识。
嗯，确实是一种矛盾，个人觉得占在效率的角度考虑的话，应该两者混用，因为效率最高，而且有可能最合理，缺点嘛就是没有美感了，破坏了OO。
做web的也有这个矛盾，完全用jsp呢还是混着html呢，结果大多数人都选择了混用，因为这样效率最高了。
内存和硬盘也是这个关系，就看怎么设计了，科学一点的话，楼主最好做个测试，在什么范围内，用oo好，什么范围内，面向数据好，当然大家基本都是写完程序跑的差不多了就next了，谁有功夫去做那么严谨的测试！
完全没看出来楼主说的面向数据有何优势，呵呵
关联关系的n+1问题，完全是设计问题，1vn一般的不会在页面上列出1和n，都是用lazy来延迟的，即使全列出来也可以用fetch来做，比直接写sql简单很多，比直接用dto少了很多冗余，因为bean可以复用
1v1的就不用说了，fetch出来即可，一样复杂的业务逻辑避免不了要用到sql，但是这种逻辑不是很多，大部分还是那几种关联和简单的crud现在的架构，很大的优势是，大部分都是自动生成，自动映射，冗余低，设计贴近现实。
強貼留名按照楼主的2种模式，
如果所有的页面和数据库完全可以对应上，
代码的多少可能仅仅是字数上的问题了吧，
就像用XML来存储数据一样，完全消除主键和外键，
也就是说完全消除表关联，如果出现这样的理想状态
这可不可以称为完全面向对象呢？......听起来很过瘾啊~~~
架构搭建，完全可以综合2点，如果你说sql语句好的，sping架构也提供了jdbc的模板。速度也很快，结合起来SS，都可以
我觉得楼主的两个方法其实没什么冲突啊，只是直接将数据层的东西送到表示层不够安全而已
而且用ORM是可以batch和lazy两设置，可以避免有太多SQL语句和一次全装载啊
我来赚点分..
  我目前的做法是尽量把数据库设计成"对象型",然后每个表对应一个数据访问对象,里面的每个方法基本上对应一个主要是操作本表的SQL语句.当然不可避免有些多表连接和更新的,看情况放在合适的对象里面.
看了简单点说 LZ的意思就是说使用ORM的时候感觉面向对象太繁琐?首先理解面向对象的话我们把对象一般看成一个整体而整体的全部部分我们并不一定都能用到既然您用了ORM框架你就应该有这种觉悟如果单挑ORM框架的缺点来讲的话那的确是有点.. 至于面向数据 LZ的意思是只取有用的部分而这样做的话那么该程序的重用性必然降低其实我认为面向对象和面向数据是一回事 (都是面向应用..) 我的老师曾经教导我从数据库里取出的数据肯定是不完整的到了程序里肯定要重新封装的所以在封装过程中就解决了您所说的问题如果说一定要说明LZ的矛盾呢也只是数据封装地点的不同而已面向对象是在程序中修改获得的原始数据而你所说的面向数据只是在获得的时候就利用SQL语句将原始数据封装成你所需要的数据这只是我的小小的看法希望有高人能总结下回帖是一种美德！
ORM一般都会有延迟加载，所以其实Set<Role>这样的是没有问题的，因为像Hibernate是根本不会去获取Role表的数据的
像Hibernate是根本不会去获取Role表的数据的
－－－
应该为在得到User对象是，Set<Role>还未初始化，这时还未获取Role表数据。当你开始访问roles属性时才会去真正加载Role表中的数据
看了这么多人的回复,很多人说的不错,有些人说到两种方式不冲突.我可以在面向对象的同时在一些特别的地方采用面向数据的方式.但有写时候做这种架构我认为应该尽量让它的模型统一.
怎么说呢,就比如我有一个非常复杂的对象关系要维护,说大点好了,我把一个人算做一个对象,这个对象里有人的名字,年龄等基本信息,也有一些其他对象的关联,比如父亲,母亲,所上的学校,这些都是关联的model,在这些关联的model里又有一些其他的关连对象,比如学校,里面可能有学校名字,学校性质等,层层关联. 项目中的成员水平参差不齐,有些时候为了方便偷偷加进去些其他属性.久之,项目过了
一段时间后难以维护.这个算不算个问题呢.反观面向数据的方式,一个模块一个DTO ,每个人管他自己的,尽管会有冗余,但看起来是比较清楚的,尤其是新的程序员刚参与项目.我现在很矛盾,我本人更倾向与少用ORM 工具,就算用也是ibatis这种半封装的,这样更容易控制,有些时候用到Hibernate,老实讲这东西要用的很好还不是那么容易的.是要花很多时间以及碰到很多问题的经验做积累的.有时他出问题了你可能根本不知道问题出在哪里.但是就用sql吧,当你看到一大串的子查询,uoin, in ,这种语句的时候,直接就要疯掉,有的sql写下来几十上百行,怎么修改.碰到性能问题怎么办?问DBA?要是没有DBA呢,要是DBA就是水的呢?
有些时候为了方便查询就是建view,确不知view的效率有多低,还要view和多个表做关联.那就更惨了.到后期view不可能去掉,只有去慢慢的优化view.有些时候想着想着觉得项目的效率与可维护性根本不能都达到,就想鱼与熊掌不能兼得