对spring框架和开发模式进行了验证。大家有什么问题或好的建议，请回复，大家一起讨论！
一、 项目目标及完成情况
目标
完成情况
技术验证和推广
完成较好。
1． 共有7人实际参与项目开发，我们引入maven2作为构建工具，eclipse作为ide环境。大家都能在很短的时间初始化项目，并快速掌握各自需要的技术（如spring，spring mvc等）进行开发。
2． 对分层开发的模式也进行了探讨，证明它是可行的：可以各层并行开发，提高开发效率；而通过分层可以隔离关注点，使得各层开发人员可以只关注本层相关技术和接口，减轻开发人员负担，提高效率。
3． 在项目活动中碰到一些技术难点，我们将解决方案文档化，然后项目内共享，这样能在碰到同样问题时快速解决。现在还是碰到问题才解决，以后需要建立预研机制，较早发现可能出现的难点，尽早解决，避免对项目进展产生影响。
4． 平台还处于建设阶段，对项目的支持还不够，需要形成一些通用的组件。
过程和管理实施
有待提高。
1． 测试1.0版已发布，目前开发1。1版，完善分页功能和采用更好的验证方式。由于对规范开发的项目周期估计不足，加上管理上的一些问题，导致项目有所延期，需要对实际的项目开发进行量化分析，确立比较准确的人员和时间计划。
2． UC文档规范和编码规范等的引入，为项目提供了较好的支持。
3． 在实施中比较缺乏必要的文档支持，如设计文档等；同时各层的接口定义也出现较多问题，导致一些开发瓶颈的出现，这都需要在正式迭代中改进。
系统功能
完成较好。
1． 完成了UC文档确定的功能点，页面美观，使用方便，能给用户较好的页面体验。
2． 采用较好的面向对象设计，能提供一定的可重用性和扩展性。
二、展现层总结
经验与教训
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． 一些通用功能如分页代码生成，还在开发中； |
