J2EE应用中运用“配置”的最佳实践

    一个典型的目录结构如下：
   

    如果你用这种方式来管理你的配置文件，有一个极大的好处就在于，不必再担心你团队的成员为找不到配置文件而发愁，他们被集中存放，集中管理了。

    当然，任何事情不能做得过于偏激，有时候，我们需要package level的配置文件，例如struts的validation，类型转化定义，i18n配置文件，等等。这些package level的配置文件，我们完全没有必要把他们集中到一起，因为他们在各自的package中承担着各自的作用。实际上，如果把他们集中到一起，反而会造成这样那样的问题，这些问题将会在第五点最佳实践中有所涉及。

    4. 选择合理的配置类型，XML or Annotation or Properties？

    之前已经谈到了尽可能简化配置，其中的重要途径是使用Annotation来代替XML进行配置。在这里我想提出的是，XML和Annotation甚至是Properties文件，他们都各自有各自的特点，我们可以根据实际情况，选择最合适的方式进行配置。

    比如说在Spring2.5中，XML配置可以被用作全局的，公共的配置，这些配置包括：DataSource定义、SessionFactory定义、事务定义等等。而Annotation可以被用作Bean定义，而无需在XML文件中一一指定。此时，两者结合将成为一个比较好的选择。

    再比如Hibernate的全局配置，可以使用hibernate.properties，也可以使用hibernate.cfg.xml。但是properties文件无法指定持久化类，不过properties文件在定义全局配置时，显然比xml的语义性更强，也更容易编辑(你只要把Hibernate发行包中的模板properties复制一份过来改一下就行了)

    而hibernate的持久化类的配置，Annotation和XML的比较上，Annotation似乎更占上风。虽然个人不喜欢在Domain Object上加过多的Annotation，不过不得不说，在降低维护成本上，Annotation占有了绝对的优势。可惜，hibernate的Annotation最大的缺点，就在于它的Annotation所定义的属性，与XML定义的属性是互相不兼容的，因而带来了一定的学习成本。

    5. 在团队工作中，尽可能不要把团队操作度很高的配置放到一个文件中

    这条最佳实践其实应该成为一条很重要的最佳实践。因为merge代码或者merge配置文件而给程序员带来痛苦的情况是数不胜数的。因此，解决这个问题的最佳方案就是尽量把团队操作度很高的配置文件拆分开。

    在项目中，那些配置的团队操作度很高呢？我大致考虑了以下一些情况：
    1) 持久化类的配置在SessionFactory中的定义
    2) web层的配置文件(struts-config.xml)等
    3) 涉及到i18n的资源类文件
    4) Spring中的Bean定义

    第一条，如果使用XML进行持久化类的配置，那么可以通过指定路径来解决这个问题。如果你使用的是Annotation，那么很不幸，当前还没有可以通过指定带有Annotation的持久化类的package的方式来简化配置。当然，要自己实现一个似乎也并不困难，有兴趣的朋友可以自己尝试一下。

    第二条，在Struts2中，已经提供了一些0配置的方案，通过使用这些方案，大家可以最大程度上降低配置的公用性。同时Struts2也支持将XML文件分开定义，每个程序员可以工作在自己那个模块所在的XML文件上。

    第三条，之前很多的做法，是在classpath下定义一个统一的资源文件，所有的资源信息都写在一起，这会造成操作冲突的几率很大。比较合适的做法，就是在Action的package level定义与这个Action相关的一些资源，这也是Struts比较推荐的做法。

    第四条，如果你使用Spring2.5，可以使用Annotation来代替Bean定义。

    6. 适度使用Annotation和CoC

    这条是值得讨论的。有关XML和Annotation的是是非非，在其他的帖子中经常有讨论。我的观点在于，对于公用的全局的配置，使用XML，而单独的Bean相关的配置，使用Annotation。对于Domain Object的配置，个人倾向使用XML配置进行关注点分离。

    谈到CoC，这是一个懒人的时代，RoR中的一些约定大于配置的观念也开始深入人心。不过在Java世界，这一点似乎还没有完全被推开。甚至有人问我，这家伙写的东西，怎么连个配置文件都没有，我哪里知道谁对应谁呢。所以CoC，我想也有个度，甚至有时候，需要一定的Reference Doc进行说明，否则，过度的CoC，也会给许多人带来困惑。

上一页  [1] [2] [3] 

【责编:Ken】