通过这一年多的艰苦奋战，项目就快接近收官之战。回首过往一年的开发历程，心中不免有些感慨万千，故写下这篇BLOG总结一下经验与教训，算是兑现上一篇BLOG的诺言。

项目简介

由于一些商业上的原因，我不能透露项目的细节。不过，我可以与大家分享一下所谓的“架构”。之所以给“架构”两字加上引号，是因为我不想玷污这个神圣的词汇。在项目开始选用第三方组件（Component）时，由于种种原因，其实我只有很小选择余地，所以只能对着一些官方文档将这些组件并揍在一起。

经验与教训

虽然我们平时说“成功的经验，失败的教训”，但是有时要区分两者并不容易，因为有些事情虽称不上成功，却也不至于失败。故请允许我暂时将其混成一谈。

#1 分而治之（divide and conquer），重构代码

在项目中当复杂业务逻辑变得复杂时，有的程序员没有胆量去重构旧代码，而取用保守方式，拼命地添加新的代码。这样做的后果就是会导致代码量激增，难于维护。“分而治之”可以帮助我们理清复杂的业务，提高代码可重用性。所以任何时候，都不要忘记这个程序基本的方法学。

#2 尽量不要使用远程（Remote）EJB

远程EJB给我们带来很多的问题：部置的复杂性，由于网络传输引起的性能问题，EJB安全性问题等。我的同事中有些人坚持使用远程EJB的原因，他们认为只有使用远程EJB才实现群集（Cluster）。其实这想法是错误，具体可以参考《Marstering Enterprise JavaBeans》第三版中，第8章“EJB Performance Optimization”中“Choosing Between Local Interfaces and Remote Interfaces”和第19章“Clustering”。

#3 避免在程序中保存状态（State）

有的程序员偏爱全局类型变量，而忽略通过参数和返回值进行共享数据。状态对程序来说其实就是一种负担，在多线程和分布式的环境下更是如此。还有，编程的另一原则是尽量缩小变量有效范围（Scope），大家可以参考一下《Code Complete》中一些建议。

另外，要小心使用静态变量，切记要通过final关键字和Collections.unmodifiableXxxx方法（对于集合类型）使其不可变。如果需要在对象之间共享状态，可以考虑使用HttpSession或分布式的缓存如（JBoss Cache等）。

#4 如果使用Hibernate，请确保程序员了解Hibernate中持久化对象生命周期

在我身边有很程序员，在使用Hibernate时，没有花时间了解持久化对象生命周期。他们以普通JDBC的编程风格编写Hibernate程序。故出现了如下所示的代码：

虽然上述代码功能上没有问题，但是反映了它的作者没有了解Hibernate的持久化对象生命周期。这里的session.saveOrUpdate其实是完全没必要的。如果你不明白个中原因，可以参考Hibernate的官方文档或《Hiberante In Action》的第四章“Working with persistent objects”。

#5 设计好你的业务对象模型

我看过很多项目的代码中其大量存在所谓的PO（Persistent Object）用于ORM和VO（Value Object）或称为DTO（Data Transfer Object）用于程序之间传输数据，更有甚者，这两种对象只是相差一两个属性。这样的做法的弊端是代码中充斥大量林林总总的copyXxx的方法，导致程序出现一些不可预期的行为。

其实，通过对业务对象分析，尤其是对象之间的关系建立，上述问题中的大部分都是可以避免的。

#6 不要单独使用JSF

经过这两年过JSF学习与使用，我对JSF是又爱又恨。JSF有不少优点：

• 类似ASP.NET的事件驱动（Event-Driven）开发模型，简化了Web应用的开发；
• 通过EL（Expression Language，表达式语言）双向值绑定，提高编程效率；
• 基于组件（ASP.NET中称之控件）的模型，方便第三方进行扩展。

不过，同样JSF缺点也不少：

• 保存过多的页面状态，而除了Session和Application范围之外的Managed Bean都是没有状态，这个不对称性导致很多问题。所以在很多时候迫使程序员使用Session范围的Managed Bean。而过度使用Session会加大服务器的内存消耗；
• 蹩脚的验证框架等。

所以，在使用JSF时，我们应该结合其它优秀的框架如JBoss Seam，RichFaces等，达到互相取长补短效果。

结言

上述评论，仅代表我本人立场:-)。如有错误，还望各位朋友不吝赐教。