编程中一个很常见的问题，有帮助的

多数情况下选第一种 这也是比较符合项目实际的 关键是log记好 异常处理和实际情况紧密结合啊 这样泛地讨论很累 不挑战了

两种结构都有道理，得看具体业务是什么啊
就拿楼主的A,B,C,D来说吧，关键是得综合业务来看，用谁调用谁合理。
第一种情况，A是一个整体协调者，业务需求在这里体现，A关系的是步骤（业务逻辑）与结果，降低了B,C,D之间的耦合度，换句话说,B,C,D直接没有交互，互相不关系对方的工作职责
第二种情况，A是一个命令发出着，将业务分散给B,C,D，A关心只是结果，将具体步骤（业务逻辑）分散到B,C,D中去
空洞的代码没有任何意义，需要结合业务才有最合理的结构，结构是死的，业务是活的

具体问题具体分析吧，没有具体的实现环境就评价是没用的，最近在读《重构》这本书，所以我还是倾向于第二种

就是因为业务是活的所以结构不能是死的。

第一种也是没办法吧
是由于页面代码与数据库代码
与业务关系小所以分成三层.....
主要还是精化业务逻辑.

如果java的业务逻辑是可以后绑定的话....
就不用分成三层了.

第一种相当于一种层次的模型，向稳定的方向依赖，看看操作系统和网络基础的模型就知道
第二种是一种策略的模型，这种模型容易扩展，架构开放，但是软件质量没法得到保障

对于层次模型，如果底层核心不抛出异常，难道要每层的代码都处理一次异常吗？

个人感觉，这两种解决方案对应的不是同一类问题。

第一种方法，明显有利于层级调用、纵向分层，类似SSH的各层关系，各层本身对于自己需要完成的事情非常了解，各层本身也比较独立；
第二种方法，是各横向模块间的协同合作完成一个功能的例子，其中隐含着顺序逻辑，调用者需要十分了解各委派对象间实现的依赖关系，适合于在小范围代码内运用。

public void save(){
    saveInfo1();
    saveInfo2();
    saveInfo3();
}

public void saveInfo1(){
    //...
    organizeData1();
    saveData1();
}

public void organizeData1(){
    //....
    verfData1();
}
public void verfData1(){
    //
}
......

觉得好像是第二种好，但是...
这个。。。如果一次保存要保存3种不同信息，分别用saveInfo1()，saveInfo2()，saveInfo3()。
单独就一个saveInfo1()来说，是lz所说的第一种吧？如果用第二种的话，在save方法里就是类似

public void save{
    organizeData1();
    verfData1();
    saveData1();
    organizeData2();
    verfData2();
    saveData2();
    organizeData3();
    verfData3();
    saveData3();
}

要是saveInfo这些更复杂的话，那save不是越来越大了嘛，他的职责是不是太多了？

针对一个结构来说就是个死的，各种死结构符合不同的活业务，就拿你举的例子来说，难道两个结构是活的么？？
我的意思是说，在举例子的时候应该结合着业务，不然哪个都是合理的。

那你脱离业务举的两个死方式的对比意义何在？