从Spring+Struts到Grails

                                        从Spring+Struts到Grails
 
 
虽然网上大量有人在宣传从Spring+Struts平台迁移到Grails平台的平缓,事实上也是如此。但资深的Spring+Struts平台开发人员迁移到Grails平台仍然需要有一些转变,其中大部分都是开发思想或者开发思路的转变。
第一.   开发方式的转变。
Spring+Struts平台的开发是平缓的,不管是CRUD,还是复杂的业务,Spring+Struts平台都要一视同仁,一步步来。对于CRUD,它的简单只是在业务层,其他的,数据层、表现层Action、页面和它们之间的配置,一个都不能少,该做的都要做到。而复杂的业务,和简单的CRUD的不同仅仅表现在业务层,多做的事情也大部分在业务层。
而Grails平台的开发则是曲线式的,先快后缓。对于CRUD式的业务,在Grails平台只要一两个动作就完成了全部的功能。当然,我们必须对页面做一定的修改,以达到客户的要求。当CRUD业务完成以后,我们再在它们的基础上添加复杂的业务。
往往从Spring+Struts平台转移过来的开发人员,会喜欢契约式的开发,而讨厌Spring+Struts的配置式的开发。对于Grails平台对CRUD开发的简化反而比较忽视,因为对于一个大型项目来说,CRUD所占的比例不大,而且很多开发人员也不认为Grails平台的脚手架产生的代码对他们有多少帮助,因为页面需要定制。
其实,从我的经验来说,对于一个大型项目,CRUD所占的比重大约为五分之一到四分之一的样子,而在小项目中,CRUD所占的比重会更大一些。因此,虽然一个大项目开发完成以后,我们不记得我们曾做过CRUD的开发,但不可否认的是CRUD的开发在Spring+Struts平台的确占了我们一部分的开发时间。Grails平台对这部分时间的节省,对我们来说也是值得庆贺的。
所以,在Grails开发平台,当然拿到一个模块的时候,我们第一步要做的,不是按照业务的要求,按部就班的进行开发;而是首先要把其中的CRUD部分抽取出来,交给Grails平台来帮我们实现。然后,我们在它的基础上去做更为复杂的业务。这就要求我们在设计SD文档和demo的时候,要尽量将业务中的CRUD抽取出来,集中而不是分散。这样有利于Grails平台来帮我们实现CRUD的功能。
 
第二.   有关契约
契约式编程相比较于配置式编程,在效率上的确高了很多。但需要注意的是,我感觉,对于大型项目来说,在编码的同时,维护一下controller、action、服务层和页面的关系仍然是有很大的必要的。但这种维护是文档式的维护,不会干扰到程序和测试服务器的运行。一旦有了这个文档,在项目的维护过程中的作用是显而易见的。当然了,这种维护要我们更为细心,不要出错。因为如果在Spring+Struts平台,配置文件出错的话,测试服务器运行时会出问题的,这也是Spring+Struts平台配置讨厌的一个原因,一个人维护出错,down过他的代码的人的测试服务器都跑不起来。但文档维护显然没有这样的纠错机制,它的正确性需要的是维护人员的细心。
就我的经验而言,使用契约的地方越多,就越需要文档。维护文档虽然会降低你的开发速度。但在项目的维护过程中,对你的维护效率的提高又是不言而喻的,特别是开发人员和维护人员不是同一个人的时候。
 
第三.   有关页面开发
传统的Spring+Struts平台的开发,我们直接把demo的页面拿来,转化成jsp文件,再在相应的位置填充所需要的变量,然后跟后台交互。
而Grails平台的开发,我们是先开发CRUD业务,即由平台帮我们生成gsp文件,然后再根据demo的页面要求,修改它的Layout和填充必要的样式。
然后,再由CRUD业务的页面铺展开来,继续完成其他的较为复杂的业务。复杂业务的gsp文件可以由demo的页面直接转化过来。
展开阅读全文

没有更多推荐了,返回首页