存档
陆老师的新书终于问世了，第一时间拿到了样书。虽然之前断断续续也看过部分书稿，但这还是第一次看到全文书稿。还没看完，但绝对是一本值得推荐的Struts2技术书籍。 Struts2作为非常常见和普及的Java MVC框架，很多项目都在用，但是我看到不少人用的时候还是很随意的。国内目前的企业应用开发领域，其实最缺的就是知其所以然。用很多人都会用，但是到底应该怎么用，什么才是最佳实践呢？ 我打算写点读书笔记，这篇算是个引子，也算帮陆老师打个广告。 购书链接： 京东 当当 亚马逊 部分章节电子版： 第二章：http://blog.demo2do.com/inside-struts2/2012/01/guideline-of-object-oriented.html 面对这些框架，大家曾经是否真的思考过，我们为什么要学习这些框架？这些框架到底从何而来？框架的本质到底是什么？使用框架，又能够为我们的开发带来什么样的好处呢？在深入分析Struts2及其源码之前，我们首先必须讨论清楚这些比框架更为核心的问题。因为只有了解了为什么，我们才能知道怎么做，才能知道如何才能做得更好。
Git好用，但是鉴于切换起来并不是毫无代价的，还是得先体验体验。懒得去搭建自己的server了，要利用网上的资源。 Provider Framework is open-source? Support for other SCM Open-source repositories Space Free private repositories GitEnterprise No No No 1Gb unlimited projects, up to 10 users repo.or.cz Yes No Yes 400M No bettercodes.org Yes SVN Yes 2Gb Yes GitHub No No Yes 300Mb No Codesion No CVS Yes 200Mb 1 user only Codaset No CVS [...]
为什么要从Subversion迁移到Git（一） 里提到了Subversion实践中遇到的一些问题。再来看看Git能不能针对这些问题有没有解决之道。 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/
以前工作中主要使用CVS，SVN作为版本控制工具，使用过程中也遇到很多不尽如人意的地方。特别是在2个方面上遇到了问题： #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 [...]
本文所提到的所有内容的前提是使用一些开源框架搭建简单的J2EE应用时，对配置的运用方面的一些总结出来的最佳实践。 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”> [...]
