站内搜索: 请输入搜索关键词

当前页面: 开发资料首页Spring 专题项目中spring分层开发的总结

项目中spring分层开发的总结

摘要: 项目中spring分层开发的总结 对spring框架和开发模式进行了验证。大家有什么问题或好的建议,请回复,大家一起讨论! 一、 项目目标及完成情况 目标 完成情况 技术验证和推广 完成较好。 1. ...
项目中spring分层开发的总结
对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.  一些通用功能如分页代码生成,还在开发中;




↑返回目录
前一篇: Learn Spring in spring(一)
后一篇: Spring与iBATIS的集成