[发明专利]一种基于注解的Web应用代码生成方法

说明书

技术领域

本发明属于软件工程计算机算法技术领域，具体涉及一种基于注解的Web应用代码生成方法。

背景技术

现有技术的方案主要从以下几个方面阐述：

一般的，软件开发过程包括：需求分析、概要设计、系统详细设计、编码、单元测试、集成测试等步骤。其中数据库表设计是系统概要设计的一部分工作。

现有技术的通常代码生成器，通常着眼于替代程序员“编码”的工具。“编码”仅仅是软件开发过程的一个组成部分，并且编码工作必须依赖于前期需求分析、概要设计、系统详细设计的工作成果。现有的技术方案，《Web应用代码生成系统的设计与实现》文献1，需要分别对控制器、视图、模型层进行配置，可以认为是基于模块的“详细设计”进行的。另外《基于J2EE的Web应用开发平台代码生成器设计与实现》的文献2，则是基于“数据库表设计”进行的。

《Web应用代码生成系统的设计与实现》文献1的技术方案，使用XML文件分别对所要生成的源代码各个层次进行配置。如图1(从文档中截图)所示，“栏目”的模块分别对模型层、控制层、视图层等的代码进行配置。由于需要分别对各个层次的代码进行配置，实际上必须在《详细设计》文档完成后，根据详细设计才能进行。这种方法的主要缺点有：(1)对于单个业务模块来说，需要分为控制层、视图层、模型层分别配置，每个层都需要配置其特定信息，例如控制层需要配置其视图的链接、执行的SQL操作等；模型层则需要配置属性的名称、类型；视图层也需要对JSP文件的名称、类型等进行配置，非常繁杂。(2)由于其配置的思想是基于单个模块进行分层次的XML配置，各层次的配置均无法指向其他的业务模块。而实际上，任何一个Web应用的模块都与其他业务对象之间存在关联，例如，某系统的员工管理模块，新增、删除、修改员工时，必然需要指定该员工的所属部门，可能采用下拉框或树型结构等方式供用户选择。《Web应用代码生成系统的设计与实现》文献1中所指的XML方式中，就无法生成与部门下拉框等相关的代码(因为无法正确引用到另外一个业务模块“部门管理”的相关内容)。

目前《基于J2EE的Web应用开发平台代码生成器设计与实现》文献2的技术方案，使用9张数据库表分别对所要生成的业务模块对应的数据实体进行配置，从图2可以看出，9张配置表围绕着业务模块对应的数据库表实体进行配置，所利用的是数据库设计输出的表结构(包括主外键关系)、系统编码等信息。数据库设计属于系统概要设计的数据模型部分，比较能够真实反映源代码中偏底层的部分(尤其是DAO层代码)。但数据库设计毕竟不能替代系统的整体设计，基于数据库设计的观念，所生成的代码将严重依赖于数据库的底层增删改查功能，而不具备对业务层、控制层的表述能力。《基于J2EE的Web应用开发平台代码生成器设计与实现》的文献所采用的数据库方式，其主要缺点为：(1)需要9张数据表用于配置，分别用于保存实体信息、实体项信息、实体外键信息、实体统计图、实体个性化信息、实体统计图个性化信息、系统编码、编码明细等9项配置。需要的配置信息繁杂，且非常琐碎，把原本整体的模块概念，分为9个不同的角度理解，并用数据库表描述其配置信息，人为增加了复杂度；(2)系统设计基于数据实体的层面，考虑的层级较低。我们知道，无论是结构化设计还是面向对象设计，都是自顶向下设计。即从用户需求出发，自顶向下设计。数据库表结构是系统分析设计的结果，以数据实体作为配置的基础，将使得系统只具备单个数据库表的增删改查功能，而不具备处理更为复杂的业务模块生成能力。例如，一个员工查询的页面，是否需要以该员工所属部门作为查询条件？这样的配置信息与数据库表结构无关，纯粹属于页面展现的配置，在现有所指的技术方案中就无法实现配置。

基于上述1和2文献的描述中，《Web应用代码生成系统的设计与实现》文献1的技术方案是基于单个业务对象(例如员工)的XML配置生成多个层次(控制器、视图、模型等)的代码；《基于J2EE的Web应用开发平台代码生成器设计与实现》文献2的技术方案是基于单个实体的9个配置表配置进行生成。而实际的业务场景远比此复杂(例如员工的增删改查必然涉及到该员工所属部门的表结构和界面展现)。因此，上述两种方案所生成的代码不具备立即编译执行的可能性，而需要人工添加各业务对象或各实体之间的关系代码，并在大量添加代码后，再进行编译调试。事实上，在大量添加各业务对象关系代码的同时，将引入很多错误，生成器对于软件工程过程所起到的效用有限。

发明内容