1。不要使用autowiring

　　Spring可以通过类的自省来自动绑定其依赖部分，使得你不必明确指明bean的属性和构造器。Bean的属性可以通过属性名称或类型匹配来实现自动绑定。构造器通过类型匹配来实现自动绑定。你甚至可以指定自动检测自动绑定模式，它可以引导Spring选择一种适当的运行机制。先来看看下面的一个例子：

< bean  id ="orderService"  
class ="com.lizjason.spring.OrderService"  
autowire ="byName" />  　

　　 OrderService类的属性名在容器中用于匹配bean实例。自动绑定可以潜在地节省一些打字和减少一些混乱。但是在现实世界的工程里你不应该使用这种方式，这是因为它牺牲了配置的清晰性和可维护性。许多指南和介绍中大量吹捧自动绑定是Spring的一种极好的特征而没有提到这一特性所带来的牺牲。依我的观点，这就像Spring中的object－pooling，它更像是一种为了占据更多市场的商业特征。它对于XML配置文件的小巧化是一个好办法，但实际上也增加了复杂程度，尤其当你运行有大量类声明的工程时。虽然Spring允许你混合自动绑定和手动绑定，但是这个矛盾会使XML配置更加晦涩难懂。

　　2.使用通俗的命名

　　这个方式对于Java编码也一样适用。在工程中使用清晰的、描述性的、协调的通俗名称对于开发者理解XML配置是十分有益的。例如对于bean ID，你可以根据通俗的Java类名来命名它。对于例子中OrderServiceDAO的bean ID命名为orderServiceDAO。对于大的工程，你可以在bean ID前面加上包名作为前缀。

　　3. 使用简洁的形式

　　简洁形式避免了冗长，是因为它从子元素中将属性值和参考写到属性中。例如下面的例子：

< bean  id ="orderService"  class ="com.lizjason.spring.OrderService" >  
    < property  name ="companyName" >  
       < value > lizjason </ value >  
    </ property >  
    < constructor-arg >  
       < ref  bean ="orderDAO" >  
    </ constructor-arg >  
</ bean >  

　　可以使用简洁形式将上述代码重写为：

< bean  id ="orderService"  class ="com.lizjason.spring.OrderService" >  
    < property  name ="companyName"  value ="lizjason" />  
    < constructor-arg  ref ="orderDAO" />  
</ bean >  

简洁形式功能在1.2版本中可以使用。对于<ref local="...">没有简洁形式。简洁形式不但可以节约你的打字，而且可以使XML配置文件清晰。它最引人注目的是当在一个配置文件中有大量定义的类时可以提高易读性。

　　4. 对于构造器参数匹配，类型名比序号好。

　　当一个构造器含有一个以上的同种类型的参数，或者属性值的标签已经被占用时，Spring允许你使用从0计数的序号来解决这些会带来混淆的问题。例如：

< bean  id ="billingService"  class ="com.lizjason.spring.BillingService" >  
     < constructor-arg  index ="0"  value ="lizjason" />  
     < constructor-arg  index ="1"  value ="100" />  
</ bean >  

　　像下面这样，利用类型属性来编写会更好一些：

< bean  id ="billingService"  class ="com.lizjason.spring.BillingService" >  
     < constructor-arg  type ="java.lang.String"  value ="lizjason" />  
     < constructor-arg  type ="int"  value ="100" />  
</ bean >  

　　使用索引可以稍稍减少一些冗长，但是和使用类型属性相比，它还是有容易发生错误的倾向和难于阅读的缺点。你应该只在构造器参数不明确的时候，才使用索引这一方法。

　　5. 尽可能重用已定义过的bean

　　Spring提供一种类似继承一样的机制来减少配置信息的复制并简化XML配置。定义一个子类可以从它父类那里继承配置信息，而父类实质上作为子类的一个模板。这就是大工程中所谓的重用。你所需要做的就是在父类bean中设置abstract=true，然后在子bean注明它自己的父类bean。例如：

< bean  id ="abstractService"  abstract ="true"  class ="com.lizjason.spring.AbstractService" >  
< property  name ="companyName"  value ="lizjason" />  
</ bean >  

< bean  id ="shippingService"  parent ="abstractService"  class ="com.lizjason.spring.ShippingService" >  
     < property  name ="shippedBy"  value ="lizjason" />  
</ bean >  

　　ShippingService类从abstractService类那里继承companyName属性的值——lizjason。如果你没有为一个bean指明类或factory方法，那么这个bean便是抽象的。

　　6. 尽量使用ApplicationContext来装配定义的bean

　　像在Ant脚本中的引用一样，Spring的引用对于装配模块化的bean来说是很有用的。例如：

< beans >  
     < import  resource ="billingServices.xml" />  
     < import  resource ="shippingServices.xml" />  
     < bean  id ="orderService"  class ="com.lizjason.spring.OrderService" />  
</ beans >

　　相对于使用import在XML配置中来预装配，通过ApplicationContext来配置这些beans，显得更加灵活。利用ApplicationContext也使得XML配置易于管理。你可以像下面的例子那样在ApplictionContext构造器里布置bean：

String[] serviceResources  =   { " orderServices.xml " ,  " billingServices.xml " ,  " shippingServices.xml " } ; 
ApplicationContext orderServiceContext  =   new  ClassPathXmlApplicationContext(serviceResources); 　

　　7. 利用id作为bean的标识符

　　你可以指定一个id或名称来作为bean的标识符。虽然使用id不会提高易读性，但是它可以让XML parser对bean的引用有效方面进行更好的验证。如果由于XML IDREF的限制而不能使用某个id，你可以利用names来作为bean的标识符。XML IDREF的限制是id必须以字母开头（或者在XML规范中定义的标点符号），后面接着字母，数字，连字号，下划线，冒号等。实际上，遇到XML IDREF限制的问题是很少见的。

　　8. 在开发阶段使用依赖检验

　　你可以在bean中给依赖检验的属性设置值，而不采用原先默认的空值，属性设置例如simple，object或all，以便容器进行依赖检验。当bean的全部的属性（或某类属性）需要被明确设置或自动绑定时，依赖检验便显得很有用。

< bean  id ="orderService"  class ="com.lizjason.spring.OrderService"  dependency-check ="objects" >  
     < property  name ="companyName"  value ="lizjason" />  
     < constructor-arg  ref ="orderDAO" />  
</ bean >

　　在这个例子里，容器确保为orderService bean设置的属性不是primitives 或者 collections。为所有的bean设置默认依赖检测也是可以的，但是我们很少这样做，是因为有些bean的属性根本就不必设置。

　　9. 为每个配置文件加上一个header comment

　　最好使用descriptive id和名称来代替在XML配置文件中的注释。此外，加上一个配置文件header也很有用处，它可以概述文件中所定义的bean。你可以选择将描述内容加入description标签中。例如：

< beans >  
     < description >  
        This file defines billing service 
        related beans and it depends on 
        baseServices.xml,which provides 
        service bean templates 
     </ description >  
 
</ beans >  

　　使用description标签的一个好处是可以容易地利用工具从标签中选取出description（的内容）。

　　10. 对于任何变化，要与队友积极交流

　　当你重构Java代码时，你需要随时更新配置文件并且通知队友。XML配置文件也是代码，它们是应用程序的至关重要的部分，但是它们难于阅读和维护。大部分时间你既要阅读XML配置文件又要阅读运行中的Java代码。

　　11. Setter injection优于constructor injection

　　Spring提供3种类型的依赖注入： constructor injection,setter injection, 和method injection。我们一般只用前两种类型。

< bean  id ="orderService"  class ="com.lizjason.spring.OrderService" >  
     < constructor-arg  ref ="orderDAO" />  
</ bean >  

< bean  id ="billingService"  class ="com.lizjason.spring.BillingService" >  
     < property  name ="billingDAO"  ref ="billingDAO" >  
</ bean >  

　　这个例子中，orderService类使用的是constructor injection，而BillingService类使用的是setter injection。constructor injection可以确保bean不会在一个非法状态下被创建，但是setter injection更加灵活并且更易管理，尤其当类存在很多属性并且其中一些是可选的情况下。

　　12. 不要滥用依赖注入

　　作为最后一点，Spring ApplicationContext可以替你创建Java对象，但是并不是所有的Java对象都通过依赖注入来创建的。例如，全局的对象不应该通过ApplicationContext来创建。Spring是一个很棒的框架，但是，就易读性和易管理性而言，当定义大量bean的时候，基于XML的配置问题就会突出。过度的依赖注入会使XML配置变得复杂而且臃肿。记住！使用强大的IDE时，例如Eclipse和IntelliJ，与XML文件相比，Java代码更加易读，易维护，易管理。

　　总结

　　对于Spring的配置，XML是很优秀的方式。但当定义大量bean时，基于XML配置会变得冗长，笨拙。Spring提供了丰富的配置选项。适当地利用其中的选项可以使XML配置清晰，但是，有些选项，例如autowiring（自动绑定），往往会降低易读性和易维护性。文章中所列举的实例，可以帮助你创建出清晰易读的XML配置文件。

说实在的,这是很理想化的设计方案,真的,我的想法也一样,之所以是这样,主要是因为我看了一本Struts的书,是奥来理出版的,里面就是这样的一个概念,虽然那本书里并没有严格按照这样的思路来做.不过也可以看出这是很完美的,但也是不可取的方案.

不可取的地方在哪里?性能问题,主要是从Service层上来的实体都可进行数据转换(DT),生成View层的DTO,单个实体是一次转换,多个实体,比如set,iterator等,就要n次转化,而这些仅仅是为了使视图层和Service层分离,这是不明智的.
不过这样的模式的出现也是有原因的.因为应用这个Service层可能会有多样的客户端,在适应多种客户端的就要用到这些东西,比如客户端是一个Swing GUI程序?那么他需要的是一个序列化的数据包,而这个数据库仅仅列出的就是健值对,为了设计简单,这个客户端就不应该知道服务器端的类以及类的联系,它仅仅依赖于Service层提攻的DTO,那么就要用到DTO,OK,现在明白robin的设计想法是相当合理,而且重用性很高的.这是大型J2EE程序所常用的方法.

但对于专用于Web而永远不打算有其它客户端的中小Web程序来言,上面的方法已经有些不合时宜了,可以说没有必要死搬了.也就是说设计应该有所退化,至于退化成什么样子,是很让人觉得为难的.我现在的思想是:所有实体对象从最顶层的视图层到最底层的持久层,都是可以共用的,这样就不存在DT的问题,那么中间过程是怎么样的呢?
我的分法是这样:

视图层
-----
控制层
-----
服务接口层
-----
业务逻辑层
-----
持久层
-----
数据库层

穿梭于其中的数据杻带是PO,也可以说它是VO.这些层从上往下依赖,比如说持久层依赖于数据库层,如果数库的设计有所变化,必然会导至持久层设计发生变化,而持久层也因此影响业务逻辑层,从而产生骨牌效应.虽然这样的设计是不好的,但是谁能够解决这样的事情呢?数据库这样最底层最核心的东西都改变了,这必然会影响整个程序的行为,比如说数据库要求多加一个计录评分级别的功能,可是原来的程序里没有这样的功能,而且所有的调用接口都没有写到这方面的功能,那么不就是整个程序只要和这个功能有关的程序文件都要进行修改,这是不可避免的(如果可以避免,请告诉我方法,小弟永生记住您的大恩).

为什么要分多一个服务接口层?很简单,主要是把业务逻辑脱离特定的Web框架,不论是在Struts、Webwork、JSF，他们都可正常运行，当然你也可以不要这一层，把业务逻辑写进Action，这样从而把程序死死绑定到了某个Web Framework，这样的好处是，程序的性能有很小的提高，不过苦果是，某一天要改成其它的Web framework呢？我建议的方案是加多一个服务接口层，这样Action主要的任务就是从接口层取得数据转到视图层去显示，这样Action的重任就很清楚了，它只是一个控制器而已（笑话，那么这些自称MVC的框架，启不只是VC而已？哈…………）

那么什么是业务逻辑层呢？因为程序并不只是涉及数据库操作,而且常会伴随一些文件操作,而这些都是对一实体的一次单元操作,而且是可重用的操作.业务逻辑层就是这样的单元操作接口，他调用持久层，更确切的说是DAO，得到PO，但后进行相关的操作。

注意，这里的持久层不是具体到Hibernate的这些ORM，而只是DAO，具体的ORM由具体的DAO实现。

呵。。。从上面这句话，也许你也会想问一个问题，具体的DAO？对，就是具体的DAO。这里就运用的面向接口编程的思想，层与层之间调用的只是接口而已，每一层都有特定的实现，而这些特定的实现是可插拔的，而且不会影响原程序的运行。你可以用Factory模式生成具体的DAO bean，呵…………这是一个痛苦的过程，而且Factory这样与程序逻辑无关的东西竟然一跃而上进入了我们的代码，这不是一个好的方法，我们可以用一种IoC框架，Spring就是一个极好的东西，注入我们想要的DAO bean，这样我们写代码就可以专心对接口编程了，我们就没有必要担心什么Factory了，呵……

那么实体呢？他能接口化吗？从我现在的所掌握的知识来看，他是不可接口化的，他是数据的载体，也是一些常规操作的载体，也正是因为这样，他是极其重要也是极其简单的，所以，他不用接口化。

好了，终于理清这半年来所思考的东西了，大至上我已经明白怎样去合理的规范化设计一个程序，现在剩下的只是挑选合适的应用框架，然后做第一个Java Web开发。汗，直到现在我都还没有真正开发过Java Web程序呢，呵…………