klyuan 多年j2ee项目开发经验，现从事保险行业j2ee项目开发。熟悉struts,hibernate,ibatis,spring框架，有丰富的项目经验，擅系统分析及j2ee中小型项目架构设计 http://klyuan.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 程序员为什么不写单元测试 klyuan 作者: klyuan  链接：http://klyuan.javaeye.com/blog/97693  发表时间: 2007年07月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

 程序员为什么不写单元测试
                       袁光东
 
笔记曾经做过一次“程序员在项目开发中编写单元测试的情况”的调查。调查结果：
1.       严格的在项目中执行TDD 几乎没有
2.       为大部份业务方法编写单元测试，并保证方法测试通过。 占16.6%
3.       偶尔编写单元测试，一般情况下不写。 占58.3%
4.       为了应付项目检查而写单元测试，但并不保证方法是否测试通过。 占8.3%
5.       从来不编写单元测试。占16.6%
因为调查具有一定的局限性或片面性，调查结果并不十分精确。也基本能够反映国内程序员编写单元测试的状况。很少有程序员能够比较认真的去编写单元测试。那么到底又是什么原因呢？根据笔者参与的多个讨论，主要有下面几种原因使程序员不编写单元测试。
1.       为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不 能按时完成编码任务,推迟项目进度。
2.       单元测试的价值不高，完全是浪费时间。
3.       业务逻辑比较简单，不值得编写单元测试。
4.       不知道怎么编写单元测试。
5.       项目没有要求，所以不编写
6.       在项目的前期还是尽量去编写单元测试，但是越到项目的后期，就越失控。
 
测试常常是程序员十分厌倦的一个项目活动。测试能够为我们带来什么？了解这些非常的重要。测试不可能保证一个程序是完全正确的，但是测试却可以增强我们对程序的信心，测试可以让我们相信程序做了我们期望它做的事情。测试能够使我们尽量早的发现程序的bug.
一个bug被隐藏的时间的越长，修复这个bug的代价就越大。在《快速软件开发》一书中已引用了大量的研究数据。指出：最后才修改一个bug的代价是在bug产生时修改它的代价的10倍。
在这里，我们需要讨论的重点是单元测试。单元测试是一个方法层级上的测试，单元测试也是最细粒度的测试。用于测试一个类的每一个方法都已经满足了方法的功能要求。
在现代软件开发过程中，不管是xp还是rup都是十分重视单元测试。已经把单元测试作为贯穿整个开发周期的一项重要的开发活动。特别是在现代软件开发过程中，有经常集成和渐近提交的方法论。总结出了非常好的单元测试理论和实践:
  在编写代码之前先编写单元测试,即测试先行
  单元测试是代码的一部份，所有的代码必须有单元测试，并使测试通过。（像在Spring这些优秀的开源项目中在这方面做出了非常好的例子）
  在修改代码之前先修改单元测试，并使它测试通过。
 
在编写代码之前先编写单元测试，会带来非常多的好处：
  在编写代码之前先编写单元测试，并不是编写代码之前需要一次性为所有的类都事先编写单元测试。这需要有一个粒度的把握。最大的粒度应该控制在一个类级别上，最合适的粒度是控制在一个方法级别上。先为某一个方法编写测试代码，然后再为该方法编写实现代码，直到其测试通过后再为另一个方法编写测试代码，如此循环。单元测试在这里已经是一个契约规范了，它规范了方法应该做什么，实现什么。测试代码远远要比难以阅读和不会及时更新的需求文档更有价值。
 测试先行，鼓励对需求的理解。如果没有理解需求，你是不可能写出测试代码的，当然你也不可能写出好的实现代码。
  测试代码与其它文档相比会更有价值。当需求发生改变，实现代码也相应改变。而往往需求文档，设计文档得不到及时更新。测试代码相比那些过期的文档更具有价值。
  测试先行可以编写出最大覆盖率的测试代码。如果在方法的实现代码编写完后再编写测试代码，这时开发人员总是编写一个正确路径的测试代码。它已经很难全面的去分析其它分支逻辑。
  如果我们采用测试先行，那么就自动的完成了为所有的类都编写测试这个实践原则。为所有的类都编写测试会将为你带来非常多的好处:
  我们可以很好的使用自动化测试来测试所有的类，特别是采用日构建的系统。
   可以让我们放心的为类或方法添加新的功能。我们可以很容易的修改测试代码并验证修改后的代码是有用的代码。
   可以让我们放心的对代码进行重构和进行设计优化。重构和设计优化通常会关联到多个类及多个方法。如果我们为所有的类都编写了测试，我们就可以在重构代码后很轻松的进行测试我们的修改是否正确。
   为所有的类编写测试，可以让我们很容易的修改bug。当接到一个bug报告后，我们总是先修改测试代码，然后修改实现代码，使测试成功。这样不会因为修改一个问题而造成新问题的产生。
良好的单元测试策略给我们增强了对程序的信心,减少了bug的产生及bug的潜伏期。降低修改bug的代价。单元测试不会是项目开发周期的某一个生命周期，它贯穿于项目的整个生命周期，是一个非常重要的日常开发活动。
 
我们已经知道了单元测试是多么重要的。为什么程序员仍然不编写单元测试呢？为什么程序员总是有理由拒绝编写单元测试呢？
一、编写单元测试，增加了工作负担，会延缓项目进度?
   这是笔者在多次讨论和调查中程序员拒绝编写单元测试的最多理由。“为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不能按时完成编码任务,推迟项目进度”。事实上真的是这样的吗？软件有着其特殊的生命周期，软件开发也具有特殊性。
首先，我们需要提供给用户的至少是一个能运行的产品。绝对不能是一堆不能运行的和充满了异味的哑代码。只有能够运行的，满足客户需求的代码才是真正有用的代码。这时代码就变成产品了。
很多程序员只关注编写代码的完成时间，而乎略了调试代码，集成及修改和维护时间。
如果没有单元测试，开发活动会是这样的情景。
以一个web应用开发为例：业务代码编写完成->打包->发布到服务器->进行功能测试->发现问题->修改代码->再打包……如此循环。
任何一个web程序员对于这种开发情景都不会感到陌生。往往不断的打包，发布，功能测试的时间是代码编写的10倍以上。通过集成系统来发现程序的bug，我们往往很难一下子准确的定位bug产生的地方。应用服务器提供的错误信息对于我们来说是非常有限的。
如果为每一个类都编写单元测试并让每一个方法测试通过，又会是怎么样的开发情景呢？
编写测试代码->编写业务代码->运行测试方法->修改代码让测试通过->所有的类都通过测试->打包->发布到服务器->进行功能测试->发现bug->修改测试代码->修改业务代码->测试通过->再打包…如此循环。
从上面的过程显而易见，我们需要花费更多的编码时间。因为需要为每一个业务类编写测试代码。但是它并不会导致我们总体需要花费更多的时间。我们只是可以非常轻松的在ide环境中运行测试方法。在代码尚未打包发布之前我们就已经确保了业务代码的正确性。当我们把所有通过测试的代码集成到应用服务器后，出现错误的机率要少得多。当集成测试后发现bug时,我们也总是先修改测试类。保证在集成之前所有的类都经过测试通过。这样功能测试的时间就成数量级的减少,所以总的花费时间要比没有单元测试要少得多。
 另外，如果没有单元测试，会经常出现一些低级的错误，如拼写错误，空指针异常等。就因为一个小小的拼写错误而需要重新打包，发布一次。如果有单元测试，就可以避免这些低级的错误。
如果没有单元测试，把代码集成到应用服务器后再发现错误时，我们往往更多的是凭借自己的经验来判断问题出在哪里。对于没有经验的程序员来说只能是撞运气了。这就像是瞎子走路一样，两眼一把黑。如果每个类都有单元测试，就无需要这么痛苦了。
这使得我回想起当年做网络系统。当时的局域网络都是采用环状网络，还没有现在的交换机来组星形网络。环状网络的传输网络采用同轴细缆线，网络中的所有节点都在一条主干线上，网络的两端都会加上一个电阻来形成一个环。
环状网络的最大的缺点就是当任意一个节点有固障时，整个网络都不能连通。维护这种网络是非常麻烦的。通常采用得比较多的方法就是“切香肠”法。把最后一个电阻取下来，接到第二台电脑的网络节点的末端，检查两条线是否能连通。连通后再把电阻取下来到第三台电脑的网络节点的末端，连上第三台电脑。这样来依次检查整个网络的线路。
后来发展了星形网络，也是现在局域网普遍采用的。有一台交换机，每一台电脑连接到交换机，任意一个节点网络故障不会影响到其它节点，检查起来就非常方便了。没有单元测试的代码就像是环状网络，而有测试的代码就像星形网络。
 其次，有可能我们第一次编写的代码是没有问题的，但是到后来需求改变而修改了其中某些类的代码，把它发布到了应用服务器去测试，所要修改的内容已经测试通过了。但是因为某些类的修改导致了其它类不能正常的工作。这种bug往往隐藏得非常深，因为只要不触动它，它就不会出现。可能会程序发布到生产环境之后才会被业务人员发现。如果每个类都有测试代码，我们在打包之前运行所有测试代码，就可以很容易的发现因为代码修改带来的连带性错误。
 其三，在离bug产生越近，修正bug就越容易；在bug产生越远，修正bug的代价就越昂贵。假设我们去集成一个星期(甚至更长时间)前编写的代码，当发现问题时，我们已经忘掉了很多重要的实现细节,所以修改变得困难重重。
编写单元测试，并不会加重程序员的负担，反而提高了程序员对程序的信心，大大的减少了重复打包，发布，纠错误的时间。这些花费的时间远远要比编写单元测试花费的时间多几个数量级。编写单元测试，可以让你更容易和更放心的去修改代码，增加功能从而加快了项目的开发进度。
为什么我们总是要主观的去认为编写单元测试会延缓项目进度呢？与其痛苦的挣扎，还不如去尝试一下好的实践。
 
二、业务逻辑简单，不值得编写单元测试
  程序员是聪明的，程序员也总是自认为是聪明的。认为一些业务逻辑比较简单的类不必要编写单元测试。我们必须承认，需求不断变化，我们也必须要有勇气去接受需求变化。编写单元测试的另一个目的就是拥抱变化，而不是拒绝变化。编写单元测试就是提高了我们对程序的信心。在敏捷软件开发中，代码为集体所有，项目组的任何一个人都可以去修改任何一个代码文件。每当我要去修改一个别人编写的代码时，我总是多么的希望有程序的单元测试代码，而往往都让我非常的失望。一般我都得花费很大的力气去猜想原作者的原始意图。也许你会说：“你可以去看需求文档啊！你不会去看注释吗？”。但实际情况是，当需求文档完成了它的使命后，开发人员就把它扔到了一边了，文档总是过期的。没有几个项目组能够使得需求，设计这些文档与最新实现代码保持一致。所以去看一个过期的文档是没有价值的。注释也同样，保持最新仍然是一个最大的问题，并且注释能够提供的信息是非常有限的。所以我最需要的就是看测试代码了。测试代码最能反映出方法最新的功能契约。由代码的编写者去写的单元测试要比由其它人去编写的单元测试要更完善,更准确。
很多问题恰恰就出在一些我们认为简单的代码中。除非是像一个JavaBean的getter和setter方法，因为这些方法可以通过IDE自动代码生成，没有必要为它编写测试。
在项目开发中，我们需要经常通过重构来优化代码及改进我们的设计,当我们对代码进行重构之后，怎么能够保证代码仍然是正确的？那就是运行所有被修改的代码的测试。如果测试通过，则说明我们的重构是正确。
我们不能回避代码的维护问题。代码维护包括修正bug和增加功能。维护工作可能会距离代码编写完成有很长一段时间。当需要修改一个bug而修改了代码，或增加一个新的功能而修改了代码时，又怎么能够保证修改后的代码仍然是正确的和没有隐患的呢？也许你会说，发布到应该服务器去测试就知道了。笔者曾经发生过因为维护而导致了更严重问题发生的情况。一个系统在生产环境正常运行很长时间了。某一天，业务人员要求修改某一个功能,笔者按业务的要求实现了要修改的功能，业务也测试了修改后的功能，然后发布到了生产环境。程序下发两个星期后，报了一个非常严重的生产问题上来，以前能够正常运行的功能突然有问题了，导致了大量的生产数据错误。这个问题是非常致命的，只能暂时停用系统。
最后我查明原因是，出错的模块与上次修改的代码有关联，上次修改时没有同时去修改现在出错的模块。要是我能够在修改代码后，运行所有的测试类，测试就肯定会报告不通过。也就不会把隐藏有这么严重错误的程序下发到生产环境去。
  我们看看没有写单元测试是怎么进行集成的。如果某些结果与我们所期望的不一致时，我们可能会在程序中加上许多print语句，然后通过控制台来监视程序的运行过程。采用print语句并不能够保证我们的程序的正确性。最好的情况是，它只能保证一条正确的路径，不能保证其它的分支。另外当太多的print语句的信息在控制台上，也会让我们看不到想看到的信息，控制台的信息是有限的。在开发测试时，把调试信息打印在控制台还可以接受，但是在生产环境，如果还有调试信息出现在控制台，那是绝对不可以接受的。我们经常会忘记把调试的print语句及时的删除掉，从而影响程序的性能。最关键的是，print语句不能保证程序的正确性，也不能为你节省开发的时间。只会给你带来负面的影响。
 
三、不知道怎么编写单元测试
  如果你相信单元测试的价值，那么去学习如何编写单元测试最终会让你获益的。
以java开发为例，junit这样的单元测试组件是非常易于学习和使用的。其它语言也有类似的单元测试组件。要相信这将是简单和能为你带来价值的。但是笔者见过许多程序员编写的单元测试完全没有起到它应有的作用。这也与不知道怎么编写单元测试有关。所以我们应该掌握一些编写单元测试的基本原则:
  应该为什么编写测试：虽然我们说为所有的代类都编写单元测试，但是测试JavaBean的setter或getter方法无异于是自寻烦恼。编写这样的测试完全是浪费时间。而且还增加了维护的困难。
  学会使用断言：断言就是让我们为方法设置一个期望值。当方法执行结果与期望值不一致时，测试组件就会报告测试不通过。我见过一些项目的单元测试不是使用断言，而是自己编写一个打印(println)工具类，可以详细的在控制台中打印出类的详细成员信息，及集合的详细信息。在单元测试中使用这个打印工具类来打印输出结果。这看起来好像非常不错。但是不应该使用这种方式来编写单元测试
使用打印工具类，需要程序员自已从控制台去观察程序的执行结果。当输出信息非常多时，控制台信息是无法向上翻屏的。所以不能够给我们提供更多的信息。所以这种方法也不能用于自动化测试。
使用打印工具类，造成了一种假像，测试报告我们的测试总是成功的！如果使用断言，当方法的执行结果与我们设置的期望值不一致时，则会详细的报告测试失败的情况。
使用打印工具来代替断言，造成测试的不充分，只会写出一个低测试覆盖率的测试。我们需要一个充分的测试。
  最大化测试覆盖率：我们除了测试一个正确的路径外，我们还需要测试方法的每一个分支逻辑。需要编写尽可能多的测试程序逻辑的测试。写一个充分的测试。
  避免重复的测试代码：测试类也是非常重要的，与应用代码一样。测试类包含的重复代码越多，测试类自身出现的错误也会越多。而我们需要做的编码工作也就越多。
  不要依赖于测试方法的执行顺序：使用Junit来进行单元测试，它不能保证测试方法按照我们的意图的顺序来执行。当一个测试类有多个测试方法时，我们不能让一个测试方法必须在某一个测试之后执行才能成功。Junit不能为我们做这样的保证，我们不能依赖于测试方法的执行顺序。
  针对接口测试：我们有“针对接口编程”的oo设计原则。同样对于测试，我们也需要针对接口测试。也就是说在编写单元测试时，测试对象总是使用接口，而不是使用具体类。
 
四、项目没有要求，所以不编写
  的确在很多项目中，团队并没有要求程序员为每一个类编写单元测试。反而会要求我们编写很多复杂的文档。作为程序员我们需要明白：程序员是编写单元测试的最大受益者。
这不是项目经理的事，也不是QA的事，而是程序员自身的事。因为单元测试是程序代码的一部份。单元测试是最好的，最有价值的文档，它应该与代码一起交付给客户。
   单元测试代码不是官僚，死板的文档。它是生动的，是程序员最有用的文档。单元测试能够提高程序员对程序的信心，能够使用养成良好的设计原则：“针对接口编程，而不是具体类”。因为要进行单元测试，所以我们需要让类独立于其依赖对象(使用Mock或stub)进行测试。这就迫使我们养成了良好的编程习惯。
  单元测试是改进我们设计的保证。做为一个优秀的程序员，是会经常优化代码和设计，所以经常的进行重构。一个优秀的程序员绝对不能容忍异味代码。而单元测试就是我们进行重构的信心保证。
  单元测试是一个日常开发活动，它贯穿于项目的整个生命周期。做一个负责任的程序员总是为自己的代码的质量负责的。是否经常改进你的设计，是否让别人很轻松的使用和修改你的代码。
为所有类编写单元测试应该是一个程序员应具有的素质。项目有没有要求，不应当成为不编写单元测试的理由。
五、为什么越在项目的后期，单元测试就越难以进行下去？
  在很多项目的初期，项目中的大部分程序员都能够自觉的去编写单元测试。随着项目的进展，任务的加重，离交付时间越来越近，不能按时完成项目的风险越来越大，单元测试就往往成为牺牲品了。项目经理因为进度的压力也不重视了，程序员也因为编码的压力和无人看官而不再为代码编写单元测试了。
  笔者所有亲历的项目都着像这么糟糕的情况发生。越是在项目的后期，能坚持编写单元测试的程序就在整个项目组中不会超过15%。为了追赶进度，绝大多数程序员都把没有经过任何测试的代码提交到版本服务器,项目经理也不再追问，照单全收。这样做的结果就是在后期，集成花费的时间越来越多，几个技术骨干人员只得日夜加班进行系统集成。好不容易集成完了之后，下发给测试人员测试时，bug的报告成数量级的增长。程序员就日以继夜的修改bug.还有非常多的bug被隐藏更深，一直潜伏到生产环境去。项目中，越来越多的人对项目失去信心，每一个人都在抱怨，数不清的bug,修正了一个bug,更多的bug报告上来。
每天都在修改bug,但是每天又会报告上更多的bug。于是开始有人想逃离了，有人请假，也有人离职。当项目总算结束时，每一个的内心都清楚，项目太烂了，还有很多的错误还没被测试出来，赶快逃离这个项目组吧！一半的人病倒了，或对项目的维护失去了信心。
为什么会这样？有没有宣导测试的重要性呢？
在项目初期应该进行宣导单元测试的重要性。
有没有做过相关的培训工作？在项目启动时，需要进行一些相关的培训，教授团队成员最基本的编写单元测试的技巧。
有没有做过相应的风险防范？越是工作资历越深的程序员，就越会拒绝编写单元测试，他们总是有太多的理由来拒绝编写单元测试。这些顽固的老程序员往往负责着核心的代码的编写。我们知道20-80定律吧。80%的错误是发生在20%的代码之中的，往往最严重的错误就发生在那些老鸟们的代码中。有没有在事先就做好风险防范，说服他们编写单元测试。
有没有做好测试相关的基础工作。有没有针对不同类型的程序编写测试基类，让编写测试变成一项非常简单的工作。有一些代码是依赖于特定的环境，如EJB访问，JNDI访问，web应用程序依赖Servlet API等。测试这些程序是非常困难的。应该编写一些测试基类和测试stub，让这些程序可以脱离于特定环境就像普通程序一样进行单元测试。让普通程序员轻松的编写测试代码进行程序测试。
可以实行日构建和测试覆盖率检查，没有通过测试的代码绝不允许放到版本服务器。检查测试的覆盖率。
 
  在现代软件开发过程中，测试不再作为一个独立的生命周期。单元测试成为与编写代码同步进行的开发活动。单元测试能够提高程序员对程序的信心，保证程序的质量，加快软件开发速度，使程序易于维护。不管测试先行还是测试后行，没有单元测试那是绝对不行的。
  弱者为失败找理由，强者为成功找方法！今天你单元测试了吗？

本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 04 Jul 2007 11:31:57 +0800 http://klyuan.javaeye.com/blog/97693 http://klyuan.javaeye.com/blog/97693 Spring JavaConfig开发指南(下) klyuan 作者: klyuan  链接：http://klyuan.javaeye.com/blog/86273  发表时间: 2007年06月03日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

lazy
Lazy
延时初始化策略
UNSPECIFIED
 
meta
Meta[]
当前bean的元数据
{}
 
scope
String
Bean的作用域
singleton
Singleton,prototype或自定义作用域
使用纯java方式的bean定义时，处理静态方法时，不再需要-Factory-method
java 代码
  1. @Bean  
  2. public ExampleBean exampleBean() {   
  3.  return ExampleFactory.createBean();   
  4. }   
 
当用方法来定义一个Bean时，这个方法必须是public的。
示例：使用aliases元素。,定义一个Bean，别名为hello
java 代码
  1. @Bean(aliases={"hello"})   
  2. public HelloWorld helloWorld(){   
  3. HelloWorld helloWorld = new HelloWorld();   
  4. helloWorld.setWord(word());   
  5. return helloWorld;   
  6. }   
  7.     
 
 
java 代码
  1. public static void main(String[] args){   
  2. ApplicationContext context = new AnnotationApplicationContext(ConfigurationFull.class.getName());   
  3. HelloWorld hello = (HelloWorld)context.getBean("hello");   
  4. hello.sayHello();   
  5.   
  6. }   
 
1.1 @ExternalBean
指定Bean是一个外部Bean
 示例:
java 代码
  1. @Configuration  
  2. public abstract class ExternalConfiguration {   
  3.        
  4. @ExternalBean  
  5. public abstract HelloWorld helloWorld();   
  6. }   
 
java 代码
  1. public class ConfigurationWithExternal {   
  2.  public static void main(String[] args){   
  3.  ApplicationContext context = new AnnotationApplicationContext(ConfigurationFull.class.getName(),ExternalConfiguration.class.getName());   
  4.  HelloWorld hello = (HelloWorld)context.getBean("helloWorld");   
  5.  hello.sayHello();   
  6.  }   
  7. }   
 
这里，在ExternalConfiguration中定义的helloWorld自动会被,在ConfigurationFull中定义的helloWorld覆盖。
所以，@ExtenalBean的意思是，这个是在父Context中定义的,这个父context可以是一个Configuration或是一个外部的xml文件。使用这个注释的好处是为了保持重构友好。
 
 
1.2 @ScopedProxy
 
Spring通过scoped proxies提供了一个方便的作用域依赖的处理方法。最简单的方式就是创建一个代理。在当使用xml配置时，使用元素。JavaConfig提供了一个等价物就是@ScopedProxy,它提供了相同的语义和配置选项。
java 代码
  1. @Bean(scope = DefaultScopes.SESSION)   
  2. @ScopedProxy  
  3. public UserPreferences userPreferences() {   
  4.    return new UserPreferences();   
  5. }   
  6.     
  7. @Bean  
  8. public Service userService() {   
  9.    UserService service = new SimpleUserService();   
  10.    // a reference to the proxied 'userPreferences' bean   
  11.    service.seUserPreferences(userPreferences());   
  12.    return service;   
  13. }   
一个userPreferences的Bean定义了Session的作用域，一个为singleton作用域的Bean userService注入了这个bean userPreferences.因为userSerivce只会被实例化一次，理论上它只会操纵一个userPreferences对象。而我们是希望它每次去从session中取回一个userPreferences对象。所以这就需要一个代理。这个代理总会在我们需要使用userPreferences对象时，自动去从session中取回userPreferences对象。
及@ScopedProxy就是提供了这样的功能。
 
2.           Bean的可见度
     JavaConfig有一个非常好的特性就是可以控制Bean的可见度。JavaConfig可以使用Java方法的可见度修饰符来决定Bean是否可以被Application Context 和Bean Factory访问
java 代码
  1. @Configuration  
  2. public class VisibilityConfiguration {   
  3.     
  4.  @Bean  
  5.  public UserInfo publicUserInfo(){   
  6.      UserInfo user = new UserInfo();   
  7.      user.setName(protectedName());   
  8.      user.setAddres(privateAddres());   
  9.      return user;   
  10.  }   
  11.  @Bean  
  12.  protected String protectedName(){   
  13.      String name = "jack";   
  14.      return name;   
  15.  }   
  16.     
  17.  private String privateAddres(){   
  18.      String addres= "Beijing";   
  19.      return addres;   
  20.  }   
  21. }   
上面三个由方法定义的Bean中，方法分别为public ,protected,private。
java 代码
  1. public class ConfigurationWithVisibility {   
  2.  public static void main(String[] args){   
  3.      ApplicationContext context = new AnnotationApplicationContext(VisibilityConfiguration.class.getName());   
  4.      UserInfo user = (UserInfo)context.getBean("publicUserInfo");   
  5.      String name = (String)context.getBean("protectedName");   
  6.      String addres = (String)context.getBean("privateAddres");   
  7.         
  8.  }   
  9. }   
 
 
当我们在Context中访问"protectedName"或"privateAddres"时都会抛出异常
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'protectedName' is defined
 
但是在VisibilityConfiguration内部，三个Bean是相互可以访问的。
所以如果在用@Bean注释的方法，如果不是public的，是不能被外部的ApplicationContext访问的。
JavaConfig 提供了Bean的可见度功能，利用Spring提供的层级应用上下文，用一个特殊的Configuration类来放置所有的隐藏Bean,在一个子应用上下文内，隐藏Bean能够访问父应用上下文定义的Bean。而父应用上下文的Bean却不能访问子应用上下文的隐藏Bean.
 
3.            Bean的依赖设置
装配一个Bean，最简单的方法就是java提供的构造函数
java 代码
  1. @Bean(scope=DefaultScopes.PROTOTYPE)   
  2. public UserInfo userInfo(){   
  3.     UserInfo user = new UserInfo();   
  4.     user.setName(name());   
  5.     return user;   
  6. }   
  7. @Bean(scope=DefaultScopes.SINGLETON)   
  8. public String name(){   
  9.     String name = "jack";   
  10.     return name;   
  11. }   
 
Bean之间依赖的设置通过bean的方法名来进行设置，并不是通过bean名称。
Name()方法被@Bean注释后，它的Bean名称是name,但是在userInfo方法，来设置name属性是仍然需要使用方法名name(),而不是bean名称name.
 
java 代码
  1. 当使用@Bean标记后，Bean都会由Spring容器进行管理。UserInfo声明为prototype,而name声明为singleton.   
  2.      ApplicationContext context = new AnnotationApplicationContext(VisibilityConfiguration.class.getName());   
  3.      UserInfo user = (UserInfo)context.getBean("userInfo");   
  4.      UserInfo user2 =(UserInfo)context.getBean("userInfo");   
  5.      System.out.println(user == user2);   
  6.      String name = (String)context.getBean("name");   
  7.      String name2 = (String)context.getBean("name");   
  8.      System.out.println(name == name2);   
  9.     
输出结果：
false
true
 
可见，被@Bean标记后，每次从ApplicationContext中获得的userInfo的对象都不是同一个对象。而每次获得的name的对象都是同一个对象。
 
4.           使用JavaConfig
   我们在前面的例子，已经多次看到了AnnotationApplicationContext的使用。现在来全面介绍AnnotationApplicationContext.
AnnotationApplicationContext提供了四个构造函数。
1.public AnnotationApplicationContext(java.lang.Class... classes)
可以把多个Configuration类构造成一个ApplicationContext
2. public AnnotationApplicationContext(java.lang.String... locations)
 除了可以接收多个完整的Configuration类构造成一个ApplicationContext外，还可以接改ant风格的类路径。
 例如：ApplicationContext context = new AnnotationApplicationContext(ConfigurationFull.class.getName(),ExternalConfiguration.class.getName());
 
ApplicationContext context = new AnnotationApplicationContext("**/configuration/*Configuration.class");
 
3.public  AnnotationApplicationContext(org.springframework.context.ApplicationContext parent)
给定一个父ApplicationContext来构造一个AnnotationApplicationContext.
 
4. public AnnotationApplicationContext()
一个默认的构造函数
 
上面这些都是针对Configuration类的。而我们更多的时候需要与xml结合进行使用。
这就需要使用到org.springframework.config.java.process.ConfigurationPostProcessor.
java 代码
  1. "1.0" encoding="UTF-8"?>   
  2. "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd">   
  3.   
  4.   
  5.   class="com.springconfig.example.chapter3.ConfigurationFull">   
  6.        
  7.   class="org.springframework.config.java.process.ConfigurationPostProcessor"/>     
  8.   
java 代码
  1. public static void main(String[] args){   
  2.     ApplicationContext context = new ClassPathXmlApplicationContext("com/springconfig/example/chapter3/applicationContext.xml");   
  3.     String word = (String)context.getBean("word");   
  4.     System.out.println(word);   
  5. }   
  6. }   
程序运行结果
HelloWorld!
 
注意，外部的xml可以直接使用Configuration中配置的Bean,而Configuration中的Bean需要使用Xml中的Bean，则需要使用@External注释。
 
 
 
 
5.           Bean的命名策略
使用JavaConfig由方法产生的Bean,其方法名就是Bean名称。但是当多个方法重名，或者有多个Congiguration或与外部xml混用时，这种方式并不合适。不同的类全覆盖彼此的定义。为了自定义bean名称产生的行为，可以能过实现BeanNamingStrategy 接口来提供它自己的bean名称产生策略
 
BenaNamingStrategy有一个默认的实现MethodNameStrategy
 
MethodNameStrategy提供了一个prefix属性，用于指定Bean的前辍的产生方式
Prefix有三个取值。
NONE:即没有前辍，仍然使用方法名作为Bean的名称。
CLASS：使用类名称为作Bean的前辍，中间以.号相连。如：ConfigurationFull.word
FQN:使用完整的类路径作为Bean的前辍。如：com.springconfig.example.chapter3.ConfigurationFull.word
 
下面就这三种方式进行说明：
java 代码
  1. "1.0" encoding="UTF-8"?>   
  2. "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd">   
  3.   
  4.   
  5.   
  6.   class="com.springconfig.example.chapter3.ConfigurationFull">   
  7.        
  8.   class="org.springframework.config.java.process.ConfigurationPostProcessor">   
  9.     "namingStrategy">   
  10.       class="org.springframework.config.java.naming.MethodNameStrategy">   
  11.           "prefix" value="CLASS"/>   
  12.          
  13.        
  14.      
  15.   
java 代码
  1. public static void main(String[] args){   
  2.     ApplicationContext context = new ClassPathXmlApplicationContext("com/springconfig/example/chapter3/applicationContext.xml");   
  3.     String word = (String)context.getBean("ConfigurationFull.word");   
  4.     System.out.println(word);   
  5. }   
  6. }   
 
程序输出：
HelloWorld!
 
把上面的prefix属性值换成FQN
java 代码
  1. public static void main(String[] args){   
  2.     ApplicationContext context = new ClassPathXmlApplicationContext("com/springconfig/example/chapter3/applicationContext.xml");   
  3.     String word = (String)context.getBean("com.springconfig.example.chapter3.ConfigurationFull.word");   
  4.     System.out.println(word);   
  5. }   
程序输出：
HelloWorld!
6.           注释还是XML
 Spring因为XML大量使用而受到了越来越多的批评，也使得基于Spring的项目变得越来越复杂。使用XML来配置Bean,它无法进行类型安全检查，当类名称或方法名被改名之后，XML中的相应配置无法随之改变。这对项目的重构带来了极大的不方便。随着JAVA EE 5,JAVA EE 6的相继推出，其中一个最大的特性就是注释的使用。当Spring使用注释来Bean时，就可以在一个纯java的类中配置Bean.因为是在纯java的环境中，可以获得编译期类型安全检查的好处,当Bean的类名或方法名进行重构修改后，Configuration中的相应的定义会被同时修改。
 JavaConfig就是为了简化Spring项目的产生的，JavaConfig的使用也非常的简单，可见JavaConfig应该是简化Spring项目的一种最好解决方式。但是并不意味着，JavaConfig就应该完全的取代xml配置。Xml的优势是就是配置的灵活性和参数化以及访问外部环境，以及在web系统中的应用。JavaConfig并不排斥xml，相反，它可以和xml很好的相结合，来降低spring项目开发的复杂度。在未来，xml应该会成为JavaConfig的补充。
 
7.           关于文档
  该文档是一个全免费的文档，可以免费传播。引用请获得作者的同意！

本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 03 Jun 2007 10:56:47 +0800 http://klyuan.javaeye.com/blog/86273 http://klyuan.javaeye.com/blog/86273 Spring JavaConfig开发指南(上) klyuan 作者: klyuan  链接：http://klyuan.javaeye.com/blog/86267  发表时间: 2007年06月03日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Spring JavaConfig开发指南
作者：袁光东
1.           什么是JavaConfig
Spring IOC有一个非常核心的概念——Bean。由Spring容器来负责对Bean的实例化，装配和管理。XML是用来描述Bean最为流行的配置方式。Spring可以从XML配置文件中读取任何类型的元数据并自动转换成相应的Java代码。Spring开变了java的编程模式，Spring的下载已经超过了1亿次,可见Spring已经有多流行。
随着Spring的日益发展，越来越多的人对Spring提出了批评。“Spring项目大量的烂用XML”就是最为严励的一个批评。由于Spring会把几乎所有的业务类都以Bean的形式配置在XML文件中，造成了大量的XML文件。使用XML来配置Bean失去了编译时的类型安全检查。大量的XML配置使得整个项目变得更加复杂。Rod Johnson也注意到了这个非常严重的问题。当随着JAVA EE 5.0的发布，其中引入了一个非常重要的特性------Annotations(注释)。注释是源代码的标签，这些标签可以在源代码层进行处理或通过编译器把它熔入到class文件中。在JAVA EE 5以后的版本中，注释成为了一个主要的配置选项。Spring使用注释来描述Bean的配置与采用XML相比，因类注释是在一个类源代码中，可以获得类型安全检查的好处。可以良好的支持重构。
JavaConfig就是使用注释来描述Bean配置的组件。JavaConfig 是Spring的一个子项目,
比起Spring，它还是一个非常年青的项目。目前的版本是1.0 M2。使用XML来配置Bean所能实现的功能，通过JavaConfig同样可以很好的实现。
 
2.           HelloWorld with JavaConfig
2.1 获得JavaConfig
JavaConfig的下载地址：
http://downloads.sourceforge.net/springframework/spring-javaconfig-1.0-m2-with-dependencies.zip?modtime=1178633399&big_mirror=0
关于JavaConfig的更多信息请访问：
http://www.springframework.org/node/455
 
2.2 HelloWorld程序
我们将以HelloWorld程序来开始JavaConfig之旅！
HelloWorld.java
java 代码
  1. package com.springconfig.example.bean;   
  2. public class HelloWorld {   
  3.    private String word;   
  4.     
  5.     
  6. public void sayHello() {   
  7.  System.out.println(this.word);   
  8. }   
  9. public void setWord(String word) {   
  10.  this.word = word;   
  11. }    
  12. }   
 
HelloWorld.java是一个非常简单的java类。只有两个方法:
setWord()设置私有变量word的值。
SayHello()打印出word的值
 
现在我们以JavaConfig来描述HellWorld这个Bean,而不是以xml方式描述。
我们需要创建一个管理类，并加上适当的注释就可以了。
 
java 代码
 
上在的代码，我们创建了一个叫HelloWorldConfiguration的类，并加上了一个类级别的注释@Configuration.
这个类中，只有一个helloWorld()的方法，返回类型为HelloWorld。这个方法，首先会创建一个HelloWorld的实例，这个实例设置word属性为"Hello world!",然后返回这个实例。
这个方法有一个方法级别的注释@Bean
看起来，这个与普通的java类并没有什么不一样。
但是这是一个非常简单的JavaConfig实现。
如果把HelloWorld用xml来描述，等价于:
java 代码
  1. "1.0" encoding="UTF-8"?>   
  2. "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">   
  3.   
  4.   "helloWorld" class="com.springconfig.example.bean.HelloWorld">   
  5.     "word">   
  6.       Hello world!   
  7.        
  8.      
  9.   
JavaConfig的使用也非常的简单
HelloWorldWithJavaConfig.java
java 代码
  1. package com.springconfig.example.chapter2;   
  2. public class HelloWorldWithJavaConfig {   
  3.  public static void main(String[] args){   
  4.   ApplicationContext config = new AnnotationApplicationContext(HelloWorldConfiguration.class.getName());   
  5.   HelloWorld helloWorld = (HelloWorld)config.getBean("helloWorld");   
  6.   helloWorld.sayHello();   
  7.  }   
  8. }   
 
程序运行后的输出结果如下：
Hello world!
 
可见JavaConfig的使用与XML一样简单，只是这里AnootationApplicationcontext替代了ClassPathXmlApplicationContext.
 
再来看看HelloWorldConfiguration类。
加上@Configuration注释后的HelloWorldConfiguration类就像一个描述Bean配置的XML文件。
加上@Bean注释后的helloWorld()方法就是一个Bean描述。Bean的ID为helloWorld.而Bean的class属性为com.springconfig.example.bean.HelloWorld.
并为这个Bean的word属性注入了值Hello world!
 
3.           JavaConfig 注释
JavaConfig使用Java代码来对配置，管理和实例化Bean.并交由Spring容器来使用。在使用XML文件来描述Bean配置时，需要定义许多专有的XML元素。而使用Java代码来描述Bean配置，是利用JDK 5 的注释特性。不管是使用XML还是Java代码，Spring都使它们在语义上保持一致。让我们看看JavaConfig中那些最重要的注释
 
3.1 @Configuration
@Configuration 标志配置类,可以在这个配置类中定义bean。在第二章我们已经接触过。
 
@Configuration
public class WebConfiguration{
//在这里定义Bean
}
 
@Configuration 等同于标签。标签的所有属性，都可以在@Configuration中进行定义。可以通过@Configuration的元素来自定义Configuration中bean的缺省的“自动织入方式”,“依赖检查方式”，“延时初始化”,及Configuration名称
 
@Configuration可选元素

元素名
元素类型
说明
默认值
取值说明
defaultAutowire
Autowire
默认自动织入方式
INHERITED
 
defaultDependencyCheck
DependencyCheck
默认依赖检查方式
DependencyCheck. UNSPECIFIED ，即不进行依赖检查
 
defaultLazy
Lazy
默认延时初始化
Lazy. UNSPECIFIED
即不进行延时初始化
 
names
String[]
Configuration名称
""，默认为空字符串
 
useFactoryAspects
boolean
是否使用切面从封装的Bean工厂自动织入
false
true,false

 
deaultAutowire标记Bean的自动织入方式，其取值在
org.springframework.beans.factory.annotation.Autowire类中进行定义。
 

模式
说明
INHERITED
不指定自动织入模式，从封装的factory中继承
NO
不使用自动织入
BY_NAME
根据名称织入bean的属性
BY_TYPE
根据类型织入bean的属性
注意：Autowire并没有定义constructor和autodetect这两种织入方式,也无需要这两种织入方式

 
DefaultDependencyCheck 标记Bean的依赖检查方式，其取值在DependencyCheck中定义

模式
说明
UNSPECIFIED
不指定依赖检可方式，从封装的factory中继承
NONE
没有依赖检查
SIMPLE
对原始类型和集合进行依赖检查
OBJECTS
对对象进行依赖检查
ALL
对原始类，集合和对象都进行依赖检查

 
DefaultLazy 标记Bean是否进行延时初始化,其取值在Lazy类中定义

模式
说明
UNSPECIFIED
不指定延时初始化Bean方式，从封装的factory中继承
FALSE
不进延时初始化Bean
TRUE
延时初始化Bean

 
 
示例：
java 代码
  1. package com.springconfig.example.chapter3;   
  2. @Configuration(defaultAutowire=Autowire.BY_TYPE,defaultLazy=Lazy.FALSE)   
  3. public class ConfigurationFull extends ConfigurationSupport {   
  4.     
  5. @Bean  
  6. public HelloWorld helloWorld(){   
  7. HelloWorld helloWorld = new HelloWorld();   
  8. helloWorld.setWord(word());   
  9. return helloWorld;   
  10. }   
  11. @Bean  
  12. public String word(){   
  13. String word ="HelloWorld!";   
  14. return word;   
  15. }   
  16. }   
  17.     
 
需要注意的是使用@Configuration来注释一个java类后，这个配置类也会被定义成一个Bean.其Bean名称为这个Configuration类的完整类名。
 
java 代码
  1. package com.springconfig.example.chapter3;   
  2.     
  3. public class ConfigurationWithElement {   
  4.  public static void main(String[] args){   
  5.  ApplicationContext context = new AnnotationApplicationContext(ConfigurationFull.class.getName());   
  6.  ConfigurationFull configuration =(ConfigurationFull)context.getBean("com.springconfig.example.chapter3.ConfigurationFull");   
  7.  configuration.helloWorld().sayHello();   
  8.  }   
  9. }   
运行程序后，输出：
HelloWorld!
 
在Configuration中访问Factory
有时需要在Configuration类中获得Factory对象，可以继承ConfigurationSupport。
 
java 代码
  1. package com.springconfig.example.chapter3;   
  2.     
  3. @Configuration  
  4. public class ConfigurationWithSupport extends ConfigurationSupport{   
  5. @Bean  
  6. public String sayWord(){   
  7. String word = (String)getBean("word");   
  8. return word;           
  9. }   
  10. }   
 
在sayWord方法中，是能过getBean方法来获得一个名为word的Bean,并返回这个Bean的值。
 
java 代码
  1. public static void main(String[] args){   
  2. ApplicationContext context = new AnnotationApplicationContext(ConfigurationFull.class.getName(),ConfigurationWithSupport.class.getName());   
  3. String word = (String)context.getBean("sayWord");   
  4. System.out.println(word);   
  5. }   
 
 
3.2 @Bean
@Bean用来在Configuration中指定一个Bean定义。方法名就是Bean名称。当然你也可以使用aliases元素来为bean取一个别名。
java 代码
  1.     
  2. @Bean  
  3. public HelloWorld helloWorld(){   
  4. HelloWorld helloWorld = new HelloWorld();   
  5. helloWorld.setWord(word());   
  6. return helloWorld;   
  7. }   
 
例如：上面的例子，spring就像创造一个名称叫helloWorld的bean。返回值为HelloWorld类型的实例。
@Bean 是一个方法级的注释，用java代码来创建和装配一个Bean实列。它相当于标签，并可以支持xml的标签提供的大部分选项，如：autowiring,lazy-init,dependency-check,depends-on,scope等。
@Bean的可选元素
元素名
元素类型
说明
默认值
取值说明
aliases
String[]
Bean的别名
{}
 
dependencyCheck
DependencyCheck
默认依赖检查方式
DependencyCheck. UNSPECIFIED ，即不进行依赖检查
 
allowOverriding
boolean
允许覆盖xml或其它Configuration的bean
false
 
autowire
AutoWire
自动织入方式
INHERITED