基于星形结构的通用业务模型的快速建模框架的制作方法【专利摘要】本发明设计了基于星形结构的通用业务模型的快速建模框架。基本思路是：框架根据后台业务模型和前台视图模型提供的信息，进行语义分析后，生成一系列资源代码来实现面向用户的增、删、查、改、显示基本应用功能的代码和资源。这些代码资源包括了：后台对业务数据处理的代码和数据库持久层服务、数据库表等等；前台默认风格的列表视图和编辑、查看视图；生成前台的控制类完成前台后台装换的逻辑；以及相关的支持系统多语言的资源文件和自动化测试代码。快速建模框架将传统由人力编写的代码资源变成由框架生成，节约了人力成本，提高了开发效率。【专利说明】基于星形结构的通用业务模型的快速建模框架【
技术领域：
】:[0001]本发明设计了一种符合领域模型驱动设计原则的快速建模工具，其基本思路是:开发人员只需要手动定义后台业务模型，框架对业务模型分析后，根据业务模型提供的信息，快速生成用户能使用的，能完成增、删、查、改、显示、自动化测试等基本功能的代码和资源，将原本需要消耗大量人力去编写的基本功能的代码资源，让框架来自动生成，一方面降低了人力开发的成本，提高了建模的速度，同时使得开发人员能够专注于特殊功能的开发。[0002]本框架基于的数据核心是一种基于星型结构的通用模型，我们称为“服务实体(ServiceEntity)”。通过星型的数据结构来描述不同的业务逻辑，使得模型的结构实现了统一化，使得框架统一数据处理，自动化建模成为可能。我们基于该星形结构的业务模型，发明了这种自动化快速建模框架。一方面提供了公共接口，能够处理不同业务模型的需求。二是基于模型本身提供的信息，能够自动生成和模型结构相关的程序代码，资源文件，自动化测试代码和默认风格的用户界面等等。相对于传统的人工开发代码的方式，开发效率进一步提闻。【
背景技术：
】:[0003]星形结构的通用业务模型简介:领域驱动开发模式的提出，使得传统的面向对象的软件开发中引入了各个部门都能使用，能交流的统一领域模型，使得软件开发更加面向实际业务需求。但是，在没有统一的业务模型支持的框架下，实际的开发模型普遍是贫血的JAVA基本数据类(JAVAPOJO类)，开发模型和业务模型有不小的区别，需要花费大量精力实现两种模型的转换；另一方面，实际的业务模型结构是千差万别的，在不同的业务场景，需要不同的方法来处理不同的业务模型，增加了开发和维护的难度。基于星形结构的通用业务模型，采用了通用的结构来描述不同场景的业务模型，一方面，使得开发模型和领域模型实现了合并，直接通过领域模型实现建模，体现而来领域驱动建模(DDD)的思想，同时，统一化的模型使得数据的处理和维护变得简化，进一步使得统一框架来实现数据处理成为可能。[0004]本发明基于JAVA的平台，基于星型结构的通用模型“服务实体”为核心。开发了一套自动化代码和资源的生成工具，可以基于用户定义的模型提供的信息，自动生成基于J2EE平台软件的代码和相关资源，实现了软件开发的生产线式生产，提高了软件开发的效率。[0005]基于J2EE平台的B/S软件通常会有下面几个部分组成:[0006]1.用户视图(UI):用户通过IE浏览器能够访问到的页面，通常为JSP页面或者html页面。在J2EE的软件中，用户通过视图来展示和操作数据。视图的特点是以某个或者某些数据模型为基础，进行数据的展示或处理，这里的数据模型，和我们前面提到的星形结构的业务数据模型不同，它是平坦结构，为视图的显示服务，称为“视图模型”。[0007]大部分的用户视图，可以分为两种类型:列表视图和编辑视图。列表视图的特点是数据源是视图模型的集合，用来显示满足要求的一系列数据，用户用列表视图来搜索满足要求的数据集合，并且可以选择其中的某些数据，进行更详细的编辑和查看工作。编辑视图，数据源是某一个特定的视图模型，编辑视图对该模型进行编辑、查看，或者新建操作。[0008]2.表示控制层:支持用户界面显示的类，它实现了两种模型的转换，即复杂结构的业务模型和平坦的图模型的相互转换，以提供给视图显示，和后台数据处理。另一方面，表示控制层对前台请求进行分发，将前台的请求，简单处理后分发给后台逻辑服务层进行进一步处理。[0009]3.逻辑服务层:用于核心的算法和业务处理控制。在服务实体的基本框架中，逻辑控制层的通过基本框架提供的方法，可以实现对服务实体模型数据的基本处理。[0010]4.数据库持久层，指具体的关系数据库中的数据库表，用于持久化存放数据。在星形业务模型的框架下，模型每一个节点的数据，对应着一个关系数据库表来存储。[0011]5.数据访问层，在应用软件中，数据访问层负责对数据库进行操作，它对上面的应用层隔离了对数据库的具体操作，提供了数据的增删查改操作。在一些JAVA的ORM开源框架中，如hibernate和ibatis，数据库访问层还包括了数据库和数据模型的映射配置文件。[0012]6.复杂结构的业务模型的建模，和平坦结构的视图模型的建模。[0013]7.其它的资源，如视图层中，控制视图多语言显示的资源文件，各个部分的自动化测试程序等等。[0014]【专利附图】【附图说明】中图二描述了传统的基于J2EE平台，基于JAVA的POJO类为数据模型的软件开发流程和工作量的情况。[0015]传统的开发方式中，开发人员除了完成模型设计的工作外，上面描述的各个部分都需要手动编写代码，需要消耗大量的时间和精力。经过观察和分析后，我们发现这样的开发工作还存在着重复性:我们开发的软件实现的功能，基本功能仍然是以数据模型为核心的的增、删、查、改、数据显示和数据间相互关系的操作，这些代码的逻辑关系可以通过数据模型的结构和关系获得。我们开发大部分代码和资源文件的可以通过数据模型和视图模型的结构和关系决定。根据这样的原理，我们设计了一个围绕着业务模型为核心的快速建模框架，通过模型得到的信息，自动化生成相关的代码和资源文件。开发人员只需要将精力花在模型的设计上，同时也大大提高了建模的速度，一旦模型设计完成，就能直接生成用户可以使用的应用。[0016]本快速建模框架的工作流程可以分为两个阶段:后台资源生成和前台资源生成。后台资源生成中，用户手动定义星形的业务模型，并且基于该模型，生成资源，如数据库表的生成，数据库表映射文件的生成，数据访问层代码的生成和逻辑服务层代码的生成，同时为前台生成默认的视图模型。第二阶段是前台资源:用户首先对自动生成的视图模型进行手动调整，去掉不需要的字段，调整字段的命名。当视图模型确定好之后，通过自动化建模工具，生成默认的JSP列表视图和编辑、查看视图，同时生成表示控制类，以实现视图模型和后台业务模型的装换，同时，基于视图模型生成视图多语言控制的资源文件和各个部分的自动化测试代码。【
发明内容】:[0017]星形结构的通用模型:服务实体(ServiceEntity)的介绍[0018]本发明设计的快速建模框架基础是星型结构的通用模型，我们称为“服务实体(ServiceEntity)”。通过统一的星型结构来描述不同的业务逻辑。在领域模型驱动开发的开发方式中，针对实际业务模型多变，维护结构各异的模型，需要消耗大量的人力、时间的问题，我们在领域驱动开发的模式下，提出了一种星形结构的通用模型，我们称为“服务实体“，模型由唯一的根节点描述和模型基本信息，根节点下面可以接一对一，或者一对多的子节点，描述模型的附加信息。不同模型之间的相互引用关系，可以由引用型模型来实现。服务实体通用数据模型的提出，实现了模型结构的统一化，降低了建模的难度，也使得数据的统一处理成为可能。[0019]【专利附图】【附图说明】中，图一，描述了一个简单的基于服务实体结构的销售订单模型。和订单本身密切相关的基本信息包括订单号，订单生成日期，经办人，优先级别等等，定义为订单的根节点信息。销售订单的附加信息，和订单本身呈现I对多关系，比如参与方的信息，我们作为销售订单的子节点。常用的销售订单包含了两个参与方，买方和买方，参与方的子节点包括的信息，应该有:参与方，主要联系人姓名。联系人电话，电子邮件，参与方角色(比如买方，卖方，供货方，提货方，付款方等等)。[0020]销售订单还包括了“销售商品”的信息，和订单呈现I对多的关系，也定义为子节点“销售商品”。销售商品中的商品自身信息应该是来自“商品”这个在销售订单外的独立的模型，比如商品的名称，商品的特点等等，“销售商品”为引用型节点，引用自“商品”这个外部的服务实体模型，“销售商品”自身包含的是和订单中销售活动相关的信息，比如用户购买数量，购买单位等等。[0021]服务实体基本框架功能的介绍:[0022]围绕服务实体的通用结构模型，我们提供了基础的框架来支持建模和基本的数据处理。开发人员可以通过框架提供的基础类，实现模型的定义，模型结构的描述。[0023]可以通过继承框架提供的基础类，通过少量的代码，实现对数据库不同类型数据访问的功能，和数据处理的基本算法。[0024]【专利附图】【附图说明】中的图三中可以看出，相对于传统的面向对象的J2EE软件开发，在引入了服务实体的基本框架后，建模开发的工作量得到了降低，由于模型结构的统一化，使得数据的处理也实现了统一化，开发人员针对每一个自定义的模型，在服务层，数据访问层，只需要很少的代码量描述模型的结构，数据的基本处理交给框架实现。然而在表示层，用户视图仍然需要开发不少的代码实现用户的需求。[0025]【专利附图】【附图说明】中，图3描述了基于服务实体的数据模型和基本框架下的开发模式，和图2中传统J2EE的开发方式相比较，数据的统一化处理，使得数据访问类和服务类的开发成本大大降低，基本的数据处理交给框架进行。但是表示层和视图层的开发，仍然需要大量的人工编码。[0026]基于服务实体的快速建模框架介绍:[0027]为了解决人工代码开发效率低下，重复劳动的问题，我们发明了基于服务实体的快速建模框架，在服务实体基本框架能够提供的基本功能，支持快速有效的建模和基本方法外。还增加了更多的快速建模工具，主要表现在:自动化代码和相关资源的生成。快速建模工具，能够根据用户定义的服务实体模型，已经面向用户界面(UI)的视图模型，进行语义分析，生成一系列默认规则的代码和相关资源，进一步提高快速建模的效率。自动化的代码和资源生成分为两个方面:1，是底层代码的生成，即用户模型结构描述代码，数据访问代码，数据库表和服务层代码的生成。2是用户界面代码的生成，包括了JSP页面，properties资源文件，和表示层控制器类的代码生成。[0028]快速框架的基本工作原理和流程:[0029]快速建模框架的工作流程可以分成两个阶段:底层代码资源生成，和表示层、视图层代码资源生成。[0030]底层代码和资源的自动生成:[0031]首先开发人员根据业务需求，手动定义服务实体模型，包括模型由哪些节点构成，节点包含哪些字段，节点间的关系，和外部节点的引用等等。[0032]自动建模框架首先通过JAVA的动态反射功能，将服务实体每个节点定义的所有字段分别解析出来，节点会生成后台数据库表，一个节点，正好也是二维关系结构，映射成一个数据库表，节点所有字段，成为数据库组成的字段。框架根据这些信息，对每一个节点动态生成一个SQL“createtable”的建表命令，框架运行SQL建表指令，在目标数据库中建立一系列关系数据库表。【专利附图】【附图说明】中，图4表示了框架根据模型中的每个节点动态生成数据库表的对应关系。同时根据当前的ORM框架，生成数据库表的映射配置文件:每一个服务实体，生成一个数据库表的映射配置文件，包含了模型所有节点类和数据库表的映射关系。[0033]同时，框架生成相应的数据模型配置类ConfigP1xy类，用来描述服务实体的结构:服务实体由哪些节点构成，节点间的相互关系。模型配置类提供的模型结构信息会在运行态时被其他类使用，以实现数据的处理。[0034]另一方面，框架生成和新定义的服务实体相对应的数据访问类DAO类，载入模型配置类类作为自定义属性，并且继承基本框架提供的标准数据访问DAO类。[0035]对服务层，生成新的服务类，并且载入DAO类和ConfigureProxy类作为自定义属性，继承基本框架提供的标准服务类。实现基本的数据算法。[0036]表示层、视图层的代码资源生成:[0037]相对于底层代码，用户界面的需求变化更大，代码和资源的自动生成难度更大。一方面用户对视图界面的需求变化较大，形式多样，另一方面，视图基于的数据模型相对于底层来说，总类更丰富，比如很多视图模型是由多个底层模型组合而成。[0038]通过长期观察总结后，我们发现B/S软件的用户界面绝大部分可以分为两个种类:I列表视图，2编辑视图。列表视图特点是它基于的数据源是视图模型的集合，以集合的方式展示满足用户搜索要求的一系列数据，用户可以进行查询，并且选中集合中的某些数据，进行进一步的编辑和查看。编辑视图是基于某一个特定的视图模型，进行编辑、查看、或者新建的操作。[0039]这两个视图可以相互嵌套，比如，一个编辑视图中可以嵌套对于子节点的列表视图。[0040]视图的数据源是视图模型，它和底层的复杂结构的业务模型不同，为了支持显示，数据模型都是平坦的结构，但另一方面，视图模型和业务模型有密切的关系:视图模型都是通过对底层“服务实体”模型进行拆分和组合而成。当视图模型包含多个底层模型的节点时，总是通过某种一比一的对应关系，将各个节点串接到一起。[0041]不同的业务场景中的列表视图和编辑视图是相互不同的，但实际上，视图模型决定了它们的形式:列表视图和编辑视图的基本功能从根本上还是对视图模型进行增删查改。不管是列表视图还是编辑实体，只要能够确定它们的视图模型，就能决定视图的显示形式。基于上述理论，我们可以通过开发人员简单的定义工作，定义视图模型的构成，基于这样的信息，生成基于该视图模型的默认显示层、视图层资源。而视图模型是由业务模型的每个节点组合而成，基于这样的原理，框架可以把一个服务实体的业务模型，节点进行“平坦化”组合，生成默认的视图模型。[0042]表示层、视图层代码资源生成的流程和原理如下:[0043]1.“视图模型”的生成。[0044]开发人员首先要定义视图模型，并且确定和后台业务模型的对应关系。[0045]由于视图模型是由业务模型的节点组合而来，开发人员不需要完全手动定义视图模型，框架可以根据业务模型，生成由所有节点“平坦化”组合而成的默认的视图模型，并且自动建立和业务模型节点的对应关系。默认的视图模型生成后，开发人员可以手动进行调整，删除不需要的字段，修改字段的命名方式等等。[0046]表示层的控制器Controller的作用是支持视图类的显示，它的作用，一方面是对视图提交的需求进行简单处理后分发给后台进行进一步处理，另一方面，控制器实现了视图模型和业务模型的相互转换。而视图模型中包含了和业务模型的转换关系，框架可以根据这些信息，自动生成默认的控制器代码，完成视图模型和业务模型转换。和支持对视图模型增删查改的操作。[0047]在快速建模框架中，视图模型和后台业务模型的转换关系包含这样的信息:视图模型包含了那些实体模型的节点，哪一个节点为“基础节点(hostnode)”出发，如何通过某种一对一的关系，遍历到下一个后台节点。我们称为“关系路线图”。在框架生成的默认视图模型中，开发人员可以提交“关系路线图”给框架，框架从路线图定义的“基础节点”开始。将自定义属性解析出来，作为视图模型的属性，并且通过框架提供的注解(annotat1n)，表明每一个节点属性和后台节点属性的映射关系。同时，框架还会自动生成一个和视图模型一对一的配置映射类(ConfigureMap)，来描述该视图模型包含了那些后台模型的节点和各个节点的对应关系，该类是用来辅助自动生成表示层视图层代码资源。框架生成的视图模型为默认的视图模型，开发人员还需要根据实际业务需要，对默认的实体模型进行调整，删除掉不需要的字段，调整命名等。[0048]2.表示层控制器和视图等资源的生成。[0049]在视图模型生成调整好后，开发人员调用快速框架，生成表示层、视图层的各个代码和资源，生成完毕后，默认的开发完毕，经过简单的调式便可以使用。[0050]表示层的控制器(Controller)的代码生成的核心和难点在于两个部分:一是基于后台“服务实体“，这个业务模型的后台数据的抽取部分，即获取后台的原始数据源，二是后台数据和视图模型数据的转换部分，即把元素业务数据转换为视图模型的数据。[0051]后台数据抽取部分:需要确定当前的视图数据，需要使用到的元素数据，怎么从后台取得，需要哪些“服务实体”的节点数据，各个节点的数据是怎么样串联起来的。[0052]后台数据的抽取部分的实现:[0053]根据前面所述，视图模型在定义时，开发人员需要定义“关系路线图”，根据关系路线图定义的“基础节点”出发，通过路线图中描述的每个节点和下一个节点的转换关系，逐步便利所有的节点，取得所有的元素数据。[0054]关系路线图“基础节点”出发，通过一对一的映射关系，不断地连接到下一个节点，这种一对一的关系，在我们的快速框架中，有下面几种形式，对应生成不同的转换代码:[0055]a.“T0_PARENT”:表示，从目标节点的角度看来，源节点到目标节点的映射关系为:源节点是父节点，目标节点是子节点。一般来说，父节点和子节点的关系可以是一对多的，但是因为视图模型是平坦结构，这里的对应关系也必须是一对一的，所以，“T0_PARENT”的对应关系，只能处理一对一的父子节点关系。系统在这种关系下生成的视图转换代码:通过目标节点的属性parentUUID等于源节点的属性UUID，根据源节点的实例，获得目标节点实例。[0056]下面给出一个生成的实例代码:目标节点是VehicleHost(车主信息)，源节点:VhicleInfoRoot是车辆信息的根节点，也是VehicleHost的父节点，它们是一比一的父子对应关系。从VhicleInfoRoot节点到VehicleHost节点采用“T0_PARENT”，生成的代码如下。[0057]VehicleHostvehiclehost=(VhicleHost)vehiclelnfoManager.getEntityByKey(vehiclelnfoRoot.getUuid(),“parentUUID”，“VhicleHost”，null)；[0058]生成的代码中，通过框架的注册服务实体工具，取得了服务视图VehicleInfo对应的服务类VehicleManager,通过调用它的方法getEntityByKey,将父节点vehiclelnfoRoot的uuid作为输入参赛,获得子节点的实例。[0059]另外，当父子节点属性是一对多时，应该采用额外的限制条件来取得一比一的目标节点实例，需要开发人员手动编码，则应采用后面提到的“OTHERS”对应关系。[0060]b.“T0_CHILD”:表示，从目标节点的角度看来，源节点到目标节点的映射关系，源节点是子节点，目标节点是父节点。这种关系在星型结构的服务实体中，一定是一对一的，生成的视图转换代码:通过目标节点的属性UUID等于源节点的属性parentUUID，根据源节点的实例，获得目标节点实例。[0061]基于上面的例子,如果是从VehicleHost连接到VehiclelnfoRoot则生成的实例代石马:VehiclelnfoRootvehiclelnfoRoot=(VehiclelnfoRoot)vehiclelnfoManager.getEntityByKey(vehiclelnfoRoot.getParentUuid()，“UUID”，“Root”,null)。[0062]c.“REF_T0_S0URCE”:这种映射关系表示了源节点到目标节点采用的是引用关系，需要调用服务层的方法通用方法getRefTarget，将源节点的实例变量作为输入参数，获得目标节点的实例变量。[0063]d.“OTHERS”:其它的转换方式，需要开发人员手动设置限制条件，比如一对多的父子关系时，需要开发人员手动设置限制条件，利用源节点的实例变量，获得一对一的目标节点实例变量。框架在这里会生成注解，提示开发人员在注解下面添加自己的转换代码。[0064]后台数据和视图模型数据的转换部分的实现:[0065]开发人员自定义的视图模型类中，所有视图模型属性，通过注释，描述了和后台业务模型的关系，即属性和业务模型哪个节点，哪个属性相对应。在自动生成控制器代码时，框架会动态搜索开发人员定义的视图模型类，将所有的属性遍历，根据属性设置的注解，找到对应的服务实体节点的属性，实现前后台代码的转换逻辑。【专利附图】【附图说明】中，图5描述了框架基于开发人员定义的“关系路线图”，生成视图模型的流程图。[0066]3.前台视图资源的生成。[0067]框架会对视图模型进行分析，生成列表视图和编辑视图，视图模型中的字段，会反应到视图中，对每个字段进行显示或者编辑，开发人员对对生成的视图进行调整，删除不需要的字段等等。[0068]同时，框架基于视图模型的各个属性，生成properties的多语言资源文件，资源文件中的字段，控制着的视图模型的字段在客户端的显示，目前默认能生成中，英文的资源文件，框架还会和已有的资源库进行匹配，找出已有默认的字段的多语言标签，其他的字段需要开发人员手动翻译，并在资源文件中配置。[0069]当所有开发的代码生成完毕后，开发人员开可以通过框架生成相关的自动化测试类，比如后台的模块，框架利用会读取服务层和数据访问层类的方法，并基于方法生成JUnit或者UnitilsJUnit4的自动测试类。另一方面，框架可以通过视图模型，生成视图类的对应测试代码。[0070]【专利附图】【附图说明】中，图4给出了基于服务实体星形结构的通用模型快速建模框架的工作流程图。通过对比图2，图3，可以看出，在快速建模框架的下，所有需要大量人工编码的工作都交给框架实现，开发人员只要建立数据模型，并给出配置信息，框架就可以生成代码实现业务需求，大大提高了建模的效率。【专利附图】【附图说明】[0071]图1描述了一个简单的“销售订单”为实例的服务实体模型的星形结构。[0072]图2描述了传统J2EE软件的开发流程和开发模式，以及工作量的情况。[0073]图3描述了基于服务实体通用模型和基本框架的J2EE软件的开发流程和开发模式，以及工作量的情况。[0074]图4描述了快速建模框架，基于业务模型的各个节点，生成底层数据库表、ORM映射文件等资源的原理图。[0075]图5描述了快速建模框架，根据服务实体模型和“关系路线图”，建立出对应的视图模型的原理图。[0076]图6描述了快速建模框架的整个工作流程和原理。【具体实施方式】[0077]1.系统准备:首先需要在JAVA工程中引入基本框架的工程包service,platform,jar,以支持建模和基本功能，在此基础上，引入快速建模框架的工程包service,installat1n,jar。[0078]2.服务实体模型建模:设计服务实体的业务模型，设计人员需要通过需求分析，建立领域模型，即服务实体模型，确定服务实体由哪些节点组成，这些节点之间的相互关系，以及和外界节点的关系。然后对每一个节点建立服务实体类，继承框架提供的基础类:ServiceEntityNode.[0079]3.生成后台代码和相关资源:写一段测试用例代码，调用快速建模框架的方法ServiceEntityInstalIat1nComProxy.registerSE(List<ServiceEntitylnstallModule>selnsList)throwsServiceEntitylnstallat1nExcept1n[0080]下面给出一段示例代码，用于调用这个快速建模方法:[0081]【权利要求】1.一种基于星型结构的通用业务模型为基础的快速建模框架，用于J2EE平台的B/S(浏览器/服务器)软件开发，自动化生成代码资源。开发人员定义好星型结构的业务模型后，业务模型定义包括组成模型的各个节点、节点的所有字段，以及节点间的相互关系。框架可以解析模型的信息，自动生成能满足面向用户对数据增、删、查、改、显示的基本应用，以及自动化测试的所有代码资源，这些资源包括:关系数据库表，数据库映射文件，支持数据持久层操作的数据访问类，提供增删查改和日志，权限控制基本功能的数据服务类，默认风格的视图页面和表示层控制类，支持视图页面多语言显示的资源文件，及各部分的自动化测试代码。2.根据权利要求1描述的星型结构的业务模型，框架可以自动解析模型的结构，包括业务模型的各个节点和节点的组成字段，每一个节点生成一条创建数据库表的SQL语句，用于关系数据库中创建一张关系数据库表，将节点中的每个字段自动映射成数据库表的列，并且生成模型-关系数据库表映射文件。3.根据权利要求1描述的数据模型，包括星型结构的业务模型和平坦结构的视图模型。其中，业务模型由开发人员手动定义，视图模型是框架基于业务模型生成，再由开发人员进行手动调整，并且自动带有用JAVA注解(annotat1n)描述的和业务模型的关系。框架基于两种模型的关系，自动生成表示层控制类代码，完成两种模型的转换和支持视图显示。4.根据权利要求1所描述的自动生成的默认风格的JSP视图页面，包括列表视图和编辑视图，列表视图数据源基于视图模型的集合，实现面向客户的数据查询，基本显示功能，编辑视图数据源基于特定选中的一个视图模型，实现面向客户的编辑，详细查看和新建功能。视图能够显示或编辑视图模型的所有字段，并且自动生成控制多语言显示的资源文件，包含了所有字段。【文档编号】G06F9/44GK104049957SQ201310079249【公开日】2014年9月17日申请日期:2013年3月13日优先权日:2013年3月13日【发明者】张航申请人:成都泰聚泰科技有限公司