项目经验和架构选择的思考

项目终于结束了，应该总结一下经验了，现说技术方面的。

项目使用EJB作为业务层开发的主要技术，但是，对我们来说确实是失败的经验。并非EJB性能或其他方面有什么问题而是：

1. 实在是太难开发了，一个SLSB（无状态Session Bean）需要维护至少5个文件：Home接口、Remote接口、Bean、ejb-jar.xml、jboss.xml，晕那。每次修改都要重新部署，JBoss号称热部署，可是很多时候根本就不行。经常是一个EJB或Web module修改完了然后部署，但是测试的结果还是原来那个，开发人员以为没有改好呢，于是就Debug，却找不到断点....象这种问题经常半天解决一个，郁闷！后来将项目分成几个子Projects，每次修改之后就Rebuild然后Redeploy，有时候甚至重新启动JBoss。回想在Tomcat下开发JavaBeans的日子，真是怀念呀。
2. 难以测试，我无法脱离容器对EJB实施单元测试，于是就写了很多JSP作测试，倒！
3. 使用了EnityBean，并没有感到不好，只是EntityBean要是能像Hibernate一样，把字段自动注入ValueObject就好了^_^
4. 没有感到StatefulBean有什么不好，只是怀疑它存在的必要性，好像结合HttpSession，SLSB也可以保存状态。

使用Struts作为MVC框架，也有不爽的地方：

1. 一大堆Actions和FormBean，很难维护呀。
2. 还有就是那个该死的配置文件，到最后变得异常庞大。尤其是JBuilder，这个项目从JB9到JB2005都用了，ModuleDirectory下挂的那一长串绿三角就是不能缩回去。JBuilder是个失败的IDE，主要原因：不支持OpenSource项目，例如Hibernate和Spring。编译JSP经常出现莫名其妙的问题，而且，每次都编译JSP干什么？好慢！

这个项目开发了很长时间了，这些技术现在看来有些落伍，这是必然的，但是最大的教训是：不要赶潮流！架构方案的选择绝对不能视技术领导的兴趣而定，更不能跟风。个人认为架构方案的选择应该考虑：

1. 具体的需求情况，这个不必说。但是还要注意一些容易忽略的地方，比如运行环境、网络带宽、客户IT资源、用户计算机水平等等。动网论坛Access版可以承受5、6百人同时在线就说明技术没有优劣，主要看使用技术的人。
2. 对所用框架的了解程度，这个要注意学习成本。最好对框架有着深刻的理解才使用，比如我不敢使用JonFramwork，虽然相信banq的DD应该不错。同时，IDE的支持也很重要，比如我不会使用PicoContainer尽管我对它的偏爱胜过Spring。
3. 不要过分依赖ORM产品。我很喜欢Hibernate，但是我以后做复杂查询的时候会开发自己的框架而不会使用Hibernate的HQL或EJB，Hibernate作CUD和简单的R是很好的，在EJB3出现之前我会一直使用，但是对于复杂的查询...
4. 注意项目的可持续发展，尽量使用主流开发技术。比如，我现在不会再使用EntityBean了因为EJB3会取代它，但是SLSB还会在特定的情况下使用，虽然EJB经常被抨击，但是我还是喜欢它。
5. 不要滥用IOC，传统的Factory还是有着不可取代的作用。考虑一个内聚性很高的模块，它通过接口与外界耦合，那么该模块的内部就最好不要使用IOC容器来管理，这会降低模块的独立性。至少不使用配置文件来体现依赖关系。可以考虑使用PiocContainer或SPring的代码装配模式。IOC应该在组件级别使用。

先想这些，以后再补充。