对SSH其实刚刚有点熟悉,就不自量力地操起键盘开始干了。jsp的课程设计,如果没意外情况,下学期的J2EE就拿它来改了。
其实开发过程还是遇到挺多麻烦的,比如说刚开始搭建环境时,就遇到许多麻烦,各种jar包冲突,神奇的报错。。。真心痛苦。
开发起初,我是老老实实按照MVC分层原理来架构的。service,DAO,Action分得清清楚楚。而且service和DAO都定义了接口,用来解耦,便于拓展。DAO来查询我所需的数据传给service,service用来处理业务流程,Action则调用service,做控制层。这么循规蹈矩虽然层次清晰,将来也便于升级,但开发效率着实堪忧。。特别是只有我一个人开发的情况下。后来随着业务的复杂,这种模式的弊端也更加显现出来。(开发效率实在太低了,要在spring里配置很多类和在struts2.xml里配置很多action)
后来,我果断放弃了这种模式,采用了新的架构。
MyAppAction统一进行业务处理,MyDispatchAction负责页面跳转,做控制层。MyAjaxAction则负责接收Ajax请求,然后它再调用MyAppAction里的方法进行业务处理。还有一个单独的DAO类MyAppDAO里面封装了几个基本的数据库操作。这样只需在spring里配置好这么几个类,再在struts2.xml里用通配符的方式,可以减少很多不必要的配置。这样子虽然到后面代码有些臃肿,特别是项目大了后,我觉得这弊端会越来越明显,但开发效率的确高了很多。
由于第一次开发,前端水平又菜。。所以跟前端数据交互做得也不咋地。刚开始是用原生jsp脚本标签(<%%>什么的)。但这个的确麻烦,而且不会帮你转换数据类型,差评。后面用了struts2的OGNL,稍微好用些。但由于技术不熟,后台封装数据装的很散乱,所以前台代码写得也很混乱。吸取教训后觉得尽量用json进行数据交互,除了一些常用的数据单独拎出来,一些数据就用map封装,前台尽量用js进行数据呈现,不要用jsp原生和OGNL,这样前后端分类得更好,便于前端人员操作,更适合分工合作。
这次实践的确对我进步挺大,跟深刻的了解了MVC思想,对SSH框架的使用也有了更深刻的认识,对J2EE也有了更深一步的了解。但整个系统还是有不少缺点,比如说开发时没有仔细考虑在服务器上跑让其他机器访问时应该注意的问题。一个是页面图片显示的路径问题(这个真心当时傻逼了),还有一个就是图片库块复制链接时的问题。我是用java后台来实现写剪贴板的(当时偷懒),也就是说别的机器用时,并不能改变剪贴板的内容,改变的是服务器剪贴板的内容。。。(现已排除以上bug,感谢wangEditor和ZeroClipboard,开源万岁。)
最后献上几张截图,献丑了。工程资源可到(CSDN_MyBlog)下载 github地址:(MyBlog_GitHub)