最后，说破了SOA精髓的还是中国人

reflection在注重减少侵入性的今天，它的作用是无可比拟的，在很多应用框架中都是基于它作为基本的实现原理。
一般一个应用在优化性能方面往往是优化关于数据库/网络/IO等等的操作上。

:lol: 我相信你的系统是这样的，但是不代表所有的系统都需要象你这样。对于很多中小型系统来说，如此优雅的架构并不都是必须的。

而且，你这样对开发的效率有影响，代码量又多啦，呵呵，对开发人员总体素质的要求也高了不少，公司的成本又高囖。 这些都是需要考虑的。:evil:

当然，我承认后一种方法的先进性和灵活性，但是，还是那个问题，不需要拿牛的杀鸡，而现在的市场，鸡还是比牛多一些。

这也是你的想当然。如果采用一个优雅的架构，普通程序员只需要编写面向对象的程序就足够了。他不需要考虑如何管理事务，他不需要考虑如何记录日志，他甚至不需要考虑如何获得和关闭数据库连接，而且他写的每个模块都可以从系统中摘出来单独测试。难道开发这样的程序会更慢、写更多的代码、对开发人员要求更高？相反，如果做太多代码级的优化，势必损害架构的优雅和灵活，会导致更多的重复代码，会使得各个模块耦合紧密而不能独立测试，那样的系统才是代码量更多、对开发者要求更高的。

我只举一个最简单的例子。你认为如果我们需要一个UserManager，那么就直接new UserManager()好了。但是这样一来，开发client代码的人就无法只测试他自己的业务逻辑，他的单元测试还必须同时兼顾UserManager的逻辑。我请问你，这是不是比写一个mock来测试自己这一个模块有更高的难度？一旦UserManager修改了实现，它的作者必须与所有使用者沟通，以保证这些人的单元测试不会失败，这是不是增加了工作量降低了开发效率？如果client代码能够这样写：

public class MyClass {
  private UserManager _um;
  public void setUserManager(UserManager um); {
    _um = um;
  }
  public void doSomething(); {
    _um.doSomething();;
  }
}

编写client的人不必考虑该创建UserManager的哪个实现类，也不必考虑如何创建，也不必关心这个对象的生命周期，也不用管它是本地对象还是RPC stub。难道这样写程序不是更轻松、代码量更少、对程序员的要求更低吗？

在实际的企业应用中，我个人所经历的和看到的是，更应该注重的是宏观上的性能（比如专门的数据层优化，UI优化），专注于毫秒一级的性能，只会让开发人员的精力分散，而最终却得不到该有的性能和效率。

灵活的架构，夸张的解耦（原谅我用夸张这个词），有些时候的确会带来一些另类的麻烦，对于较小的项目来讲更是如此。但是如果项目的开发量大到一定程度的时候，这些架构的优势就能相对体现出来。在性能的优化上，尤其是如此。这并不是说这些架构的性能有多么的出色，相反通常就架构而言，可能性能是有一定的损耗的，不过重要的是这样的架构提供了可以专门对数据层和界面交互层进行独立优化的基础。而就某一方面进行专门的独立的优化，其性能的提高，是非常显著的，并且是整个项目受益的。

大体上就是这样了。还是那句话，“最好的优化就是不优化”，专心于建模和结构。存在性能问题的话，对某方面做独立的优化。大项目尤其如此。

不懂soa. 不过, 这个

ServiceRequest bsr = this.getApplicationContext();.getBean("businessServiceRequest");; 

bsr.setServiceName("User Services");; 
bsr.setOperation("addUser");; 
bsr.addRequestInput("param1", "addUser");; 

String userIDRetured = (String); bsr.service();;

也太麻烦了啊. 不管什么效率, 至少, 它复杂, 繁琐, 静态类型安全也被彻底牺牲掉了. 灵活性在哪里? 没看出来.
我从来不认为依赖reflection是什么灵活性. 相反, 一般情况下,依赖reflection只能损害灵活性.

在正规公司里面，分工明确的话，都是专人写好架构，普通程序员按照架构往里面填代码就是的啦。正常情况下，他也是不需要如何管理事务，记录日志，获得和关闭连接，每个模块也可以单独测试。

但是，程序调试出错的时候，他们也需要自己查看日志，考虑一下各方各面的因素才能调试，按照第二种写法，无疑，这些程序员的素质要相对高一些，考虑的问题更多一些，才能进行调试的。



这个是例子这么写的，需要灵活的部分，我们自然会用其它方法写。不过在最简单的情况中，我们是会这么写，更简单的情况，直接还调用静态方法，不会不给吧，呵呵

别的不多说，就说这一件事好了。我要求所有程序员严格遵循“针对接口编程”的原则，每个组件必须提供一个接口和一个实现，获得组件必须以接口的形式、通过dependency injection获得。而按照你的说法，你要求程序员在提供功能时有时针对接口编程，有时针对对象编程，有时静态方法实现，也就是说你要求程序员清楚这三种设计的语义区别和利弊权衡。我想请问你，究竟是谁对程序员的要求更高呢？

确实，在大项目架构更灵活，将来修改就越方便，整体性能调优就越容易，所以如果是一个很大的系统，我们也会考虑全面采用spring。

不过有些复杂地方，使用spring还是不够的，有时一个对象的创建，可能要结合几种设计模式，兜兜转转，才能产生一个，然后才通过spring把它set到client里面去。但是这不意味着我们整个系统就都要这样了，spring最大的好处之一，也就是这个吧，不强迫你全部使用。

   佩服佩服，没有程序员抗议嘛？

我们现在是这样，不过，这个好像是JAVA程序员的基本功吧，虽然现在很多程序员基本功不好，那样的话，还是我们要求高点，按照你那样写的话，都快可以机器产生代码了，呵呵，可以考虑开始向自动产生代码发展了。

不过嘛，还是那个问题， 出了bug，你们调试还是比较困难点吧？

对象怎么创建、对象的生命周期怎么管理，这些都是跟业务没关系的infrastructure。让程序员可以不操心这些infrastructure，一心关注自己的业务逻辑，怎么会有人抗议？

你说“调试比较困难”，我就真的很怀疑你究竟有多少经验了。任何一个有经验的J2EE开发者都会知道，OOD做得越好，debug越轻松。OOD做得好，你才可能做出完备的单元测试，然后用单元测试快速锁定debug的范围。我们调试比较困难吗？我真的不知道该怎么回答这个问题，因为我已经好久没开过debugger了。