Struts2作为非常常见和普及的Java MVC框架，很多项目都在用，但是我看到不少人用的时候还是很随意的。国内目前的企业应用开发领域，其实最缺的就是知其所以然。用很多人都会用，但是到底应该怎么用，什么才是最佳实践呢？

我打算写点读书笔记，这篇算是个引子，也算帮陆老师打个广告。

购书链接： 京东 当当 亚马逊

部分章节电子版：

第二章：http://blog.demo2do.com/inside-struts2/2012/01/guideline-of-object-oriented.html

面对这些框架，大家曾经是否真的思考过，我们为什么要学习这些框架？这些框架到底从何而来？框架的本质到底是什么？使用框架，又能够为我们的开发带来什么样的好处呢？在深入分析Struts2及其源码之前，我们首先必须讨论清楚这些比框架更为核心的问题。因为只有了解了为什么，我们才能知道怎么做，才能知道如何才能做得更好。

您可能也喜欢：
六点J2EE应用中运用“配置”的最佳实践	2009年2月份壁纸推荐	[搜网志]Prototip2 重装上阵	IE8 beta2重装上阵 无法忽视的雷蒙德巨头
无觅

对于普通用户来说，比较重要的几件事情，是否支持私有库，比如最大牌的GitHub免费账号要求项目必须开源，空间有多大，GitEnterprise看上去很诱人啊。当然剩下就是得试试看，在墙内哪个速度更合适一些。

Git最基本的认证方式是使用基于SSH的公钥认证，经常在xNix下工作的同学应该不用讲这个了吧。就单独说一下Windows怎么生成公钥（public key）。

首先是下载 Win32下的Git，推荐 msysgit http://code.google.com/p/msysgit/

然后去X:\\Documents and Settings\yourname\.ssh\ 下打开id_rsa.pub文件，里面的内容就是你的public key

您可能也喜欢：
为什么要从Subversion迁移到Git（二）	为什么要从Subversion迁移到Git（一）	35套让人惊艳的图标下载（免费）	一组免费的(FREE)的超炫WordPress Theme
无觅

Git在提交对象（Commit）上有着和Subversion不一样的设计，在Subversion中每一次提交只有一个父版本，而Git的每次提交可以有多个父版本，这一不同的设计，让Git在比赛伊始就牢牢占据了主动。

来看一下最基本的分支合并过程

这是最简单的状态，trunk在c2创建了iss53分支来进行issue53相关，然后trunk和branch同时在提交更改。这里可以看到大部分提交也只是单父版本状态。

和Subversion依靠mergeinfo来做合并判别，Git要更为聪明，会寻找两个分支的共同祖先（Ancestor），来进行三方合并。再简单合并情况下，很容易的就能完成合并过程。

对于合并的版本c6，很显然这就是一个双父版本的提交版本，从简单的版本树变成了DAG(Directed acyclic graph)。这样的特性让合并的复杂度大幅降低，也让长期分支的设想有了足够的工具支持。前文提到的双向合并也不再是让人痛苦的工作了。

对比一下Subversion的合并设计吧：

图片来源：http://progit.org/book/zh/ch3-2.html

Git在合并之外还提供了一种途径，衍合（rebase），即把分支上c3的更改，把diff依次衍合进trunk。这可以很有效的消除杂乱的分支提交历史。让所有分支上的改动最终在trunk上显得是有序的。

如果你也经常为Subversion带来的手工工作感到厌倦，试试看Git，也许会省下不少时间。

参考文档：

http://progit.org/book/zh/

http://ventspace.wordpress.com/2011/03/09/understanding-subversions-problems/

http://altdevblogaday.org/2011/03/09/its-time-to-stop-using-subversion/

您可能也喜欢：
为什么要从Subversion迁移到Git（一）	介绍几家免费的Git托管服务	国外主机专题（一）：为什么选择国外主机	Wiki维基百科2008年募集呼吁文言文版本
无觅

#1 网络访问受限情况下无法在本地维护版本

#2 SVN分支合并会遇到各种问题

为了更好的折腾，开始在项目里引入Git的辅助，争取将来部分新项目迁移到Git上面去。那先来看看Subversion使用过程中遇到的问题。先看第一个问题，网络中心服务器的强依赖。

CVS|SVN为代表的集中版本控制

Git|Mercurial为代表的分布式版本控制

图片来源： http://progit.org/book/zh/ch1-1.html

因为分布式的设计，显然对网络中心服务器的依赖就消除了，当然分布式设计的初衷并不仅仅局限于此。那么第二个问题是不是能够得到很好的解决呢？我们先看一下SVN分支合并中为什么会出现各种问题。

Pre Subversion 1.5

在1.5之前，Subversion不存储任何分支（Branch）合并有关的信息，也就是说你无法知道当前分支曾经做过哪些合并。

      1   2   4     6     8
trunk o-->o-->o---->o---->o
       \
        \   3     5     7
b1       +->o---->o---->o

branch b1的HEAD是r7，trunk的HEAD是r8，当我们将b1合并回trunk后，版本树变成如下

      1   2   4     6     8   9
trunk o-->o-->o---->o---->o-->o      "the merge commit is at r9"
       \
        \   3     5     7
b1       +->o---->o---->o

trunk的HEAD变成r9，包含b1上r3-r7的更改。但是随着开发的进程，版本不断增长，版本树会变成什么样子呢？

           12        14
trunk  …-->o-------->o
                                     "Okay, so when did we merge last time?"
              13        15
b1     …----->o-------->o

这时候你是否还记得上一次合并发生在什么版本上？在一个比较大的项目中，这将是非常糟糕的局面。并且带来一个Subversion 合并（Merge）中很常见的问题，两个分支的文件比较时没有使用共同的祖先（ancestor），你是否经常被3个冲突（conflict）文件所困扰。

以上大部分内容摘自 http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn

Post Subversion 1.5

1.5开始，Subversion做出了改变，开始存储分支合并信息以解决上面提到的问题。那是不是就不再有其他问题了呢？我们来看一下现在是怎么来完成分支合并工作的。

      1   2   4     6     8   9(M)
trunk o-->o-->o---->o---->o-->o      "the merge commit is at r9"
       \      \            \
        \   3  \  5(M)      \ 7
b1       +->o---+>o--------->o

我们修改一下之前的例子，我们将trunk r4合并到分支b1，然后当分支开发完成后，我们进行Reintegrate合并，Subversion会检查svn:mergeinfo，从trunk r4开始合并分支上的改动回trunk，然后提及到r9完成Reintegrate合并。

的确这样解决了我们遇到的大部分问题。唯一已知的问题，就是一旦完成Reintegrate合并回trunk，该分支不应继续保留，如果你还需要继续保留分支，并且继续同步trunk上的改动，那就会陷入完全不可知的冲突地狱。解决方法是，删除当前分支，重新创建一个。为了尽可能的透明，你可以创建一个同名的分支。

客观的说，1.6以后的Subversion解决了90%的问题。基于上面提到的问题，SVN不建议保持长生命周期的分支（long period branch），或者称为稳定分支（stable branch）。这样整个分支管理就需要更加富有经验和技巧。

      1   2   4    11(cherry picking from b1)
trunk o-->o-->o-------->o------->o-------------------->o
          \            /         \r15                 / ? can we reintegrate ?
           \   3      /           \r16(sync merge)   /
featrue b1  +->o----->o------------>o-------------->o

考虑这样的情况，我们从trunk上创建了一个功能分支（feature branch），开发过程中发现一些改动/bug fix需要提前合并回trunk，如果我们在r11这个节点执行一次选择合并（cherry picking）回trunk，那之后如果继续像一般情况下不断同步trunk到功能分支，同时也不断把功能分支的svn:mergeinfo的起点“reset”。最终，我们在结束功能分支开发的时候，Reintegrate merge将变的不可用，并且合并的历史也会变的非常复杂。这时候就需要你对Subversion整个合并的原理非常熟悉，才能很好的去解决这个问题，否则只能带来大量的手工合并。

先有冲突，后有阿鼻。

（未完待续）

更新于：2011-06-11 @ 11:45

您可能也喜欢：
为什么要从Subversion迁移到Git（一）	介绍几家免费的Git托管服务	国外主机专题（一）：为什么选择国外主机	Wiki维基百科2008年募集呼吁文言文版本
无觅

1. 尽最大的可能简化你的配置

这一点似乎是基本原则，没有人会愿意多写一行代码，配置也是代码，多一行配置，就意味着多一行的维护量。简化配置的主要途径大致有:
1) 尽可能减少配置文件的数量
2) 使用语义鲜明的Annotation来代替复杂的XML文件配置
3) 使用CoC来代替配置文件
4) 使用一些特殊的技巧来简化配置文件的内容

2. 分离关注点，让配置文件各尽其用

这一点似乎与第一点有所背离，不过事实上，分离关注点对于配置文件的可维护性是非常重要的一点。

举一个针对Spring+Hibernate的配置场景作为例子。通常我们需要一个Spring的配置文件(applicationContext.xml)，来配置DataSource和SessionFactory，由于Spring本身提供了针对Hibernate的Global属性进行配置的选项，所以，其实我们可以通过如下的配置文件，对Spring+Hibernate完成配置：

<bean id=”sessionFactory” class=”org.springframework.orm.hibernate3.LocalSessionFactoryBean”>
<property name=”mappingResources”>
        <list>
           <value>com/demo2do/demo/entity/User.hbm.xml</value>
           <value>com/demo2do/demo/entity/Order.hbm.xml</value>
           <value>com/demo2do/demo/entity/Admin.hbm.xml</value>
        </list>
    </property>

    <property name=”hibernateProperties”>
        <props>
           <prop key=”hibernate.dialect”>org.hibernate.dialect.MySQLDialect</prop>
           <prop key=”hibernate.show_sql”>true</prop>
        </props>
     </property>
</bean> 

在这里，我们发现，一个SessionFactory的配置实在太长了，一旦我们需要对其中的某些配置进行改动，就需要用肉眼去观察我们所需要修改的配置片段。在项目开发过程中，我们会发现，这个文件的这个配置片段修改频度会非常高，因为在一个团队中，每个人都可能需要增加一个持久化类，或者对hibernate进行一些全局化的配置修改。结果，这段配置可能会在版本管理上造成merge的混乱。

所以，我们可以在这个基础上对这段配置进行重构，重构的原则就在于把Hibernate的配置和Spring的配置进行关注点分离。我们选择hibernate.properties对Hibernate的一些Global的选项进行指定。同时使用指定持久化类hbm配置文件路径的方式，批量定义持久化类。重构后的配置文件变成了2个：

<bean id=”sessionFactory” class=”org.springframework.orm.hibernate3.LocalSessionFactoryBean”>
    <property name=”mappingDirectoryLocations”>
            <list>
    <value>classpath*:persist/system</value>
    <value>classpath*:persist/role</value>
    <value>classpath*:persist/activity</value>
    <value>classpath*:persist/extension</value>
    <value>classpath*:persist/user</value>
            </list>
        </property>
</bean>  

######################
### Query Language ###
######################

#################
### Platforms ###
#################
## MySQL

hibernate.dialect org.hibernate.dialect.MySQLInnoDBDialect
hibernate.connection.url jdbc:mysql://127.0.0.1:3306/test
hibernate.connection.username root
hibernate.connection.password root
## Oracle
#hibernate.dialect org.hibernate.dialect.OracleDialect
….

此时，我们可以发现，程序员可以独立工作，不需要为增加持久化类修改公共配置而烦恼，hibernate.properties也更加清晰的反映hibernate相关的配置。

这还不够，因为在项目中，我们往往可能在不同的DataSource的实现上切换。多数情况下，我们会使用类似C3P0这样的数据连接池，当然，也可能会通过JNDI来指定我们的DataSource。所以，我们在这里很有必要对JDBC连接相关的关注点再一次进行分离。引入一个jdbc.properties的文件指定JDBC相关的链接信息，并在Spring配置文件中导入这些配置：

<!– A Local dataSource Definition using c3p0 connection pool –>
 <bean id=”dataSource” class=”com.mchange.v2.c3p0.ComboPooledDataSource” destroy-method=”close”>
  <property name=”driverClass” value=”${connection.driver_class}”/>
  <property name=”jdbcUrl” value=”${jdbc.connection.url}”/>
  <property name=”idleConnectionTestPeriod” value=”${jdbc.pool.c3p0.idle_connection_test_period}” />
  <property name=”preferredTestQuery” value=”${jdbc.pool.c3p0.preferred_test_query}” />
  <property name=”maxIdleTime” value=”${jdbc.pool.c3p0.max_idle_time}” />
  <property name=”properties”>
   <props>
    <prop key=”user”>${jdbc.connection.username}</prop>
    <prop key=”password”>${jdbc.connection.password}</prop>
    <prop key=”c3p0.acquire_increment”>${jdbc.pool.c3p0.acquire_increment}</prop>
    <prop key=”c3p0.max_size”>${jdbc.pool.c3p0.max_size}</prop>
    <prop key=”c3p0.min_size”>${jdbc.pool.c3p0.min_size}</prop>
   </props>
  </property>
 </bean>
 
 <!– Hibernate SessionFactory definition using exposed dataSource –>
 <!– hibernate.properties and hibernate.cfg.xml will be loaded on startup –>
 <bean id=”sessionFactory” class=”org.springframework.orm.hibernate3.LocalSessionFactoryBean”>
  <property name=”dataSource” ref=”dataSource”/>
  <property name=”mappingDirectoryLocations”>
            <list>
    <value>classpath*:persist/system</value>
    <value>classpath*:persist/role</value>
    <value>classpath*:persist/activity</value>
    <value>classpath*:persist/extension</value>
    <value>classpath*:persist/user</value>
            </list>
        </property>
 </bean>

connection.driver_class=com.mysql.jdbc.Driver

jdbc.connection.url=jdbc:mysql://192.168.1.251:3307/test
jdbc.connection.username=root
jdbc.connection.password=root

jdbc.pool.c3p0.acquire_increment=2
jdbc.pool.c3p0.max_size=20
jdbc.pool.c3p0.min_size=2
jdbc.pool.c3p0.preferred_test_query=’SELECT 1′
jdbc.pool.c3p0.idle_connection_test_period=18000
jdbc.pool.c3p0.max_idle_time=25000

这样，一段配置变成了3个文件。但是通过重构，我们可以轻松在本地实现数据库切换(修改jdbc.properties)，数据连接池切换(修改jdbc.properties和applicationContext.xml)，hibernate的Global配置切换等功能。这些功能会提供你更加灵活的调试方式。

3. 整理你的配置文件，不要让它们分散到各处

这一点作为一个最佳实践提出来，主要是因为在项目中，我们可能使用到的技术框架和配置文件是很难预期的。而默认情况下，这些配置文件所存放的位置也不同，比如Spring，往往会把applicationContext.xml文件放在WEB-INF/目录下，而hibernate和struts默认是放在classpath下的。这就为管理配置文件带来了不便。所以，一个比较好的做法，是把我们的配置文件都放在一起。通过存放在不同的目录结构进行管理。例如，把所有的配置文件都放到classpath下。

如果你用maven进行项目管理，maven会为你创建专门存放配置文件的目录(通常是一个叫做resource的目录)。如果不使用maven，我们也可以做类似的工作。以我个人的习惯为例，我喜欢在项目中建立一个叫做conf的source folder来存放所有的配置文件。由于conf是一个source folder，所以它会被类似eclipse这样的IDE自动编译到classpath下，那么我们就可以在这个目录下创建一些package，例如context的package专门存放Spring相关的配置文件，persistent专门存放ORM相关的配置文件，web专门存放表示层的配置文件。而其他的一些配置文件，则直接放到conf根目录下。

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

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

当然，任何事情不能做得过于偏激，有时候，我们需要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，也会给许多人带来困惑。

您可能也喜欢：
推荐一本新书《Struts2技术内幕》	SwitchHosts! 轻松切换HOST配置	手把手教你把Vim改装成一个IDE编程环境(图文)	[搜网志]Prototip2 重装上阵
无觅