从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的页面直接转化过来。