项目中spring分层开发的总结

对spring框架和开发模式进行了验证。大家有什么问题或好的建议，请回复，大家一起讨论！

一、 项目目标及完成情况<!----><o:p></o:p>

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

二、展现层总结<o:p></o:p>

经验与教训

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；

三、业务层总结<o:p></o:p>

经验与教训：

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

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

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

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

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

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

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

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

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

待解决问题：

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

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

四、持久层总结<o:p></o:p>

经验与教训：

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

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

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

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

待解决问题：

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

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

<o:p> </o:p>