一、 项目目标及完成情况

二、展现层总结

经验与教训

1.         SpringMVC是一个简洁、标准的MVC实现，结构清晰，功能强大（主要体现在对日常WEB开发中可能遇到的各种常见问题的解决方案），有一定学习曲线，但是有其它MVC框架基础的开发人员可以较快上手；

2.         根据业务功能尽早确定接口，接口由展现层确定，由业务层实现；

3.         合理选择Controller可以减少开发工作量，前提是充分理解每种Controller的处理机制及其回调方法细节，Controller的编写更多的精力主要花在校验、出错处理上；

4.         页面工作量很大，特别是需要比较复杂javascript的页面；

5.         UI的流转设计等对于Controller的编写和业务层的接口有着很大的影响，应尽早明确，否则会产生较大的返工；

6.         展现层开发可以与业务层同步进行，推荐确定接口后，就编写业务层接口的mock实现，放在展现层的test包内，同时写单独的测试用spring配置文件；

待解决问题

1.         Controller是否应写test case，本次开发未做；

2.         如何减少校验的工作量，对于有业务逻辑的服务端校验如何实现，是否需要采用一些validator框架，如sun的JEF的validator组件，目前我们进行了研究，通过使用commons validator组件能够较方便的实现validator；

三、业务层总结

经验与教训：

1.         Spring，iBatis的应用还是很成功的，学习曲线比较平滑，好的框架好掌握；

2.         比较重视测试，编写很多测试案例，并频繁使用maven运行所有测试，使得问题能够及早发现，保证了各层能够快速成功集成

3.         对于很多问题都需要经过各层间的讨论来确定；

4.         接口由展现层定义，由业务层实现；

5.         持久层数据模型和领域模型是有区别的，但简单的情况下可以合二为一；

6.         Façade模式还是很有价值的；

7.         一些开源软件的使用需要比较小心，如iBatis的null的问题等，如果处理不当会花费较多的人力物力，需要技术较强的人对开源软件花费一定时间进行源码级的研究，才能找出较好的解决方案；

8.         认识到设计的重要性，需要对前置、后置条件等进行分析；

9.         数据类型分析简单，造成数据库设计对业务层产生不良影响；

待解决问题：

1.         沟通不够，需要建立沟通渠道，是否可以有专门的场合和时间讨论项目中的进度和问题；

2.         计划不明确，对于要完成哪些功能，完成到什么程度，没有明确的定义，需要设置里程碑目标。在正式迭代开始前，要明确每次迭代的任务和目标，需要结合业务需求进行计划；

四、持久层总结

经验与教训：

1．  通过代码生成工具，能够大大提高开发效率；

2．  工具使用者要求对ibatis和sql比较了解；

3．  在使用过程中对工具进行了完善，这对正式使用工具提供了保证；

4．  与业务层的接口，应该由业务层确定，由持久层实现，而不是由持久层决定；

待解决问题：

1．  持久层的测试该如何进行，才能真的有用；

2．  一些通用功能如分页代码生成，还在开发中；

spring和hibernate我也是刚学，各看了本书，然后搞了搞spring的sample，就是那个jpetstore和petclinic，一个是用ibatis，一个用hibernate做persistence层。同时有一个刚进公司的人跟着我做，我也就得先把项目初始化好，写好配置文件，分好包和层次结构，然后放cvs上。既然用spring＋hibernate，配置文件肯定是很多的，我基本是参照petclinic，分了dao, dao.hibernate, model, model.logic, service, web这几个包，配置文件定义了applicationContext.xml，app-servlet.xml(我用spring mvc) , log4j.properties，jdbc.properties, mail.properties，说到spring的配置文件，其实也不复杂，搞懂了它的IoC（DI）和AOP就很容易配了，层次定义清楚，在头脑中对谁ref谁有概念，基本就不大会配错了。错了也没关系，它的log功能强大，定义好log4j，出了什么错都能有详细的记录。我搞spring的sample时就是把这个配置改改，那个删掉，自己写个类，替换它的。。。。。。这样很快就对它的配置文件有了深刻的理解。这次算是我第一个正式用spring的项目，但因为前面在理论上和零星的实践中对它有了较深的认识，也就大大降低了项目的风险（技术预研真的很重要啊！）。

虽然是小项目，但也得规范一下，定好项目计划，统一大家使用的工具和环境，简单交代编程的注意事项，如代码规范，cvs的使用，多写test类等。我们采用eclipse3.1+ myeclipse+tomcat5+mysql作为各自的开发和单元测试环境，上线使用websphere5+db2。我是要求先在mysql上能跑，然后能方便的迁移到db2上的，这样方便进行单元测试，也能在事实上与数据库解耦合，用hibernate很容易做到这一点。

但要能顺利的上线到websphere5，我就没什么把握了，毕竟它还是使用ibm 的jdk1.3，而且很多东西跟tomcat不同，更会不会有什么lib冲突等问题。我先把兼容性测试放在了开发的前面，否则在tomcat上开发好了，websphere不支持或出现难以解决的问题，就麻烦了，严重的可能要推倒重来。因为没在实际项目中使用过spring，周围又没什么人可问（我毕业一年多，没有高手指导，全靠自学和实际项目中领悟），所以有这些疑问也是正常的。不管如何，先把项目在tomcat上跑起来再说。改了一通配置文件，配好tomcat的数据源，往mysql加一个最简单的表（id一个字段），写了2张最简单的jsp（测试spring mvc的multiaction用），一个jsp显示从数据库获得的id。开启和关闭几次tomcat（我比较粗心大意，配错好几处），id就能在页面上显示了。Tomcat上基本配置完成，这也忙了个3、4个小时。

然后就是做兼容性测试了。我们有个websphere的测试环境，先把项目deploy到它上面。测试环境没用ND，我先deploy到server1上，这样能重启应用。Deploy完成，页面都出不来，500错，应用就没起来。先看日志，哇！一堆错。分析日志，好像是先装载的DispatcherServlet, 然后才是ContextLoaderServlet，当然出问题了，不过至少说明它找到了lib下的spring.jar也能work。我使用的Listener而不是Servlet来load context，估计是这个原因导致的，tomcat工作正常，websphere对Listener就不保证先启动了。于是改成使用Servlet，tomcat测试通过，我将改过的web.xml覆盖服务器(这里要覆盖2个地方，一个是应用下的，还有一个config/cells…..下的)， 重启应用，再看日志，还是错。不过这次是先启动ContextLoaderServlet了，但一上来就错了，报错：javax.naming.NamingException: Attempted to use a 4.0 DataSource from a 2.3 (or higher) servlet。这不是spring的问题，呵呵！我用的数据源V4，结果用了j2ee2.3，再改web.xml，头上改成用j2ee2.2，再覆盖，再启应用。这次首页出来了，看日志，一切正常。呵呵！没那么多问题嘛，jdk1.3照样跑最新的spring和hibernate。

今天从零开始把spring和hibernate跑了起来，也算是一次不错的实战，就作为spring+hibernate实战的第一篇吧，接下来几天，我在项目中的体会也会记录下来，当成一个一个系列吧。