可以用来解决不同类型的问题。
界面上经常出现“总-分”模式，就是先看列表，然后从列表再看某一项的详细信息，
列表往往来自多表关联的结果，更适合采用你说的”数据驱动“，直接为特定的SQL查询设计DTO，
而详细信息页面往往是一个对象入口，用1-N的关系检索出相关信息（就像你说的用户-角色），
那么用你说的”对象驱动“模式更合适。
手段本身没有优劣之分，就看用的是不是恰当，
即便从数据库开始设计，作出对应的java类，也不影响再进一步封装不和表对应的DTO。
楼主认为呢？
------解决方案--------------------
面向对象的思想发展与C/S结构的基于数据库的软件架构，对象在客户端和服务器创建之后可以一直使用重复利用，所以C/S模式可以充分利用其优点，分散其缺点
但对于大规模用户访问的b/s结构不同，客户端不能创建对象，对象全部在服务器端创建，如果不平凡销毁再创建，
那么对于访问量大的系统内存需求却是难以估量，平凡销毁再创建同样是一个灾难
所以，没看过门户，社交类网站会用面向对象来设计
面向对象的B/S还是适合小型的（员工数量低、没有分公司）企业服务软件的
面向数据对开发人员要求较高，web， server，datebase都需要精通，全能型的
不管如何，没有哪种架构是绝对使用于的，需要综合考虑
------解决方案--------------------
完全没看出来楼主说的面向数据有何优势，呵呵
关联关系的n+1问题，完全是设计问题，1vn一般的不会在页面上列出1和n，都是用lazy来延迟的，即使全列出来也可以用fetch来做，比直接写sql简单很多，比直接用dto少了很多冗余，因为bean可以复用
1v1的就不用说了，fetch出来即可，一样
复杂的业务逻辑避免不了要用到sql，但是这种逻辑不是很多，大部分还是那几种关联和简单的crud
现在的架构，很大的优势是，大部分都是自动生成，自动映射，冗余低，设计贴近现实。
------解决方案--------------------
------解决方案--------------------
像Hibernate是根本不会去获取Role表的数据的
－－－
应该为在得到User对象是，Set<Role>还未初始化，这时还未获取Role表数据。当你开始访问roles属性时才会去真正加载Role表中的数据
