著录项信息
专利名称 | 处理界面元素与数据映射的系统及其实现方法 |
申请号 | CN201310732978.2 | 申请日期 | 2013-12-26 |
法律状态 | 授权 | 申报国家 | 中国 |
公开/公告日 | 2014-04-02 | 公开/公告号 | CN103699649A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | G06F17/30 | IPC分类号 | G;0;6;F;1;7;/;3;0查看分类表>
|
申请人 | 成都市卓睿科技有限公司 | 申请人地址 | 四川省成都市高新区紫瑞大道188号附6号
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 成都市卓睿科技有限公司 | 当前权利人 | 成都市卓睿科技有限公司 |
发明人 | 曹剑 |
代理机构 | 四川省成都市天策商标专利事务所 | 代理人 | 刘兴亮 |
摘要
本发明的处理界面元素与数据映射的系统及其实现方法,允许分开定义界面元素需要的数据传输模型与数据访问的实体模型,然后通过应用服务将两种模型进行相互转换和操作,通过将数据传输模型转换为数据访问实体模型实现通过界面对数据添加、修改;通过将数据访问实体模型转换为数据传输模型实现数据的查询。这种引入的中间应用服务层可以将界面元素与后台业务逻辑有效分割,实现更清晰的架构与更统一的处理。
处理界面元素与数据映射的系统及其实现方法\n技术领域\n[0001] 本发明涉及信息技术、分析及测量控制技术领域,具体涉及一种处理界面元素与数据映射的系统及其实现方法。\n背景技术\n[0002] 现代应用服务中,无论是客户服务器模式还是浏览器服务器模式的应用服务都会涉及到对数据库的访问,比如针对SQL Server的访问。当我们的应用服务通过界面需要对数据进行添加、删除、修改或查询时,通常会对对应的数据库一个表或多个表进行访问或操作,传统的操作方式是通过界面直接访问或操作数据库中得一个表或多个表,这种传统的方式会带来两个问题,一是界面和业务逻辑以及数据访问混和使用,架构不清楚,另一个是没有一种统一的方法来分割处理界面元素与领域模型的方法。\n发明内容\n[0003] 本发明克服了现有技术的不足,提供一种将界面元素与后台业务逻辑有效分割,实现更清晰的架构与更统一的处理界面元素与数据映射的系统及其实现方法。\n[0004] 考虑到现有技术的上述问题,根据本发明公开的一个方面,本发明采用以下技术方案:\n[0005] 一种处理界面元素与数据映射的系统,包括:\n[0006] 数据库;\n[0007] 用户在界面元素上进行操作产生的数据传输对象;\n[0008] 实体模型,所述实体模型上包含与所述数据传输对象对应的实体对象,在产生所述数据传输对象的情况下,所述数据传输对象与所述实体模型映射;\n[0009] 应用服务层,所述应用服务层解开所述数据传输对象与所述实体模型产生的映射,以得到需要的用户信息实体;\n[0010] 业务逻辑层,通过所述应用服务层后得到的用户信息实体与所述业务逻辑层映射,以得到或者创建相应的实体对象信息,该实体对象信息通过\n[0011] 数据访问层持久化到所述数据库中。\n[0012] 为了更好地实现本发明,进一步的技术方案是:\n[0013] 根据本发明的一个实施方案,所述实体模型位于所述应用服务层上。\n[0014] 根据本发明的一个实施方案,\n[0015] 所述应用服务层包含对数据传输对象与所述实体模型上的相应实体对象的相互转换。\n[0016] 本发明还可以是:\n[0017] 一种处理界面元素与数据映射的方法,包括:\n[0018] 用户在界面元素上进行操作产生的数据传输对象;\n[0019] 在实体模型上设置有包含与所述数据传输对象对应的实体对象,在产生所述数据传输对象的情况下,所述数据传输对象与所述实体模型映射;\n[0020] 通过应用服务层解开所述数据传输对象与所述实体模型产生的映射,以得到需要的用户信息实体;\n[0021] 使所述应用服务层后得到的用户信息实体与所述业务逻辑层映射,以得到或者创建相应的实体对象信息,该实体对象信息通过数据访问层持久化到所述数据库中。\n[0022] 根据本发明的一个实施方案,所述实体模型位于所述应用服务层上。\n[0023] 根据本发明的一个实施方案,所述应用服务层包含对数据传输对象与所述实体模型上的相应实体对象的相互转换。\n[0024] 与现有技术相比,本发明的有益效果之一是:\n[0025] 本发明的处理界面元素与数据映射的系统及其实现方法,允许分开定义界面元素需要的数据传输模型与数据访问的实体模型,然后通过应用服务将两种模型进行相互转换和操作,通过将数据传输模型转换为数据访问实体模型实现通过界面对数据添加、修改;通过将数据访问实体模型转换为数据传输模型实现数据的查询。这种引入的中间应用服务层可以将界面元素与后台业务逻辑有效分割,实现了更清晰的架构与更统一的处理。\n附图说明\n[0026] 为了更清楚的说明本申请文件实施例或现有技术中的技术方案,下面将对实施例或现有技术的描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅是对本申请文件中一些实施例的参考,对于本领域技术人员来讲,在不付出创造性劳动的情况下,还可以根据这些附图得到其它的附图。\n[0027] 图1示出了本发明实现用户信息创建示例框图。\n[0028] 图2示出了根据本发明一个实施例的用户信息创建时的示例性图形用户界面。\n[0029] 图3示出了根据本发明一个实施例的用户信息创建时的示例性图示。\n[0030] 图4示出了用户信息创建时各个系统间的信息流动、处理的示例性序列图示。\n具体实施方式\n[0031] 下面结合实施例对本发明作进一步地详细说明,但本发明的实施方式不限于此。\n[0032] 图1示出了根据本发明一个实施例的实现用户信息创建示例框图。如图1所示本发明示例实施例方案,旨在说明各参与人或系统在本发明的方法中的职能,本发明并不局限于此一种实现。不排除某些实施例方案在某些方面增加辅助附加功能。\n[0033] 用户使用任意浏览器101通过互联网102访问创建用户信息界面,用户服务平台\n103收到用户创建消息后,会创建用户传输对象与用户实体对象映射,并交给应用服务平台\n104进行处理,应用服务平台104的应用服务会解开映射,并得到用户信息实体105,并通过业务逻辑层106创建用户信息实体对象,将对象交给数据访问层系统107进行处理,数据访问层系统107将对象持久化到数据库中。\n[0034] 图2示出了根据本发明一个实施例的用户信息创建时的示例性图形用户界面。如图2所示示例性界面,旨在示例一般情况下OA系统创建一个用户信息的交互主要元数据,而并不限定界面的布局及样式,也不限制其他实施例界面附加其他交互数据。\n[0035] 208处输入用户的用户名;209处选择用户的性别;210处选择用户所处的部门,211处选择用户的生日。以上文本框的组合,可能会因实际情况其可选项有不同的集合。\n[0036] 208处用户名作为用户登录OA系统的账户名,系统据此账号标示用户。209处选择用户的性别,性别可以选择男或女。210处选择用户所处的部门,部门是在其他功能在创建的。211处选择用户的出生日期。填好无误后,用户在212处提交。当提交成功,用户会收到创建用户信息成功的消息提示,并且显示创建的用户的用户名。\n[0037] 图3示出了根据本发明一个实施例的用户信息创建时的示例性图示。如图3所示,旨在说明满足本发明创建用户方法所需关键数据的流向及处理,并不局限在此流向及处理过程中仅包含在此所述之数据。\n[0038] 301处为创建用户信息时各种界面元素的确定,302处系统会自动把界面元素视为一个数据传输对象,303处显示在进行创建时,应用服务先将数据传输对象转换为实体对象,304处会将得到的实体对象方法,通过调用业务逻辑的创建实体对象方法,305处通过得到创建的对象并通过持久化到数据库存储中。\n[0039] 图4示出了用户信息创建时各个系统间的信息流动、处理的示例性序列图示。如图\n4所示为完成创建一个用户信息的业务参与各方及各系统间的信息流动、处理的示例性顺序。1)用户在界面上输入或选择创建用户的各个方面的信息;2)创建信息会交给用户服务层处理;3)用户服务层会自动创建用户信息数据传输对象与用户信息实体对象的映射,并调用应用服务层的创建对象方法;4)应用服务层创建对象方法会解开映射的数据传输对象与用户信息实体对象,并调用业务逻辑层的创建对象方法;5)业务逻辑层调用持久化对象到数据库的方法并返回用户信息创建成功信息。\n[0040] 综上所述的一种处理界面元素与数据映射的方法,实体模型可以位于应用服务层上,也可以是单独的;通过实体对象、数据传输对象的相互转换,不但便于数据的创建、查询、传输,而且在对各个模块进行修改的时候可以单独进行,如在对业务逻辑层进行修改时,可以不对其它部分进行修改。\n[0041] 在实体模型上设置有包含与所述数据传输对象对应的实体对象,在产生所述数据传输对象的情况下,所述数据传输对象与所述实体模型映射,如在用户界面创建“姓名”,则相应的在实体模型上映射出相应的“姓名”实体属性,此时创建的映射包括了需要的信息,也可能包括多余的信息;因此,需要通过应用服务层解开所述数据传输对象与所述实体模型产生的映射,以得到需要的用户信息实体,此时解开的方法可以是现有技术中通常采用的方法;使所述应用服务层后得到的用户信息实体与所述业务逻辑层映射,以得到或者创建相应的实体对象信息,例如以上的“姓名”在业务逻辑层上相应实体对象信息,该实体对象信息通过数据访问层持久化到所述数据库中。\n[0042] 本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其它实施例的不同之处,各个实施例之间相同相似部分相互参见即可。\n[0043] 在本说明书中所谈到的“一个实施例”、“另一个实施例”、“实施例”、等,指的是结合该实施例描述的具体特征、结构或者特点包括在本申请概括性描述的至少一个实施例中。在说明书中多个地方出现同种表述不是一定指的是同一个实施例。进一步来说,结合任一实施例描述一个具体特征、结构或者特点时,所要主张的是结合其他实施例来实现这种特征、结构或者特点也落在本发明的范围内。\n[0044] 尽管这里参照本发明的多个解释性实施例对本发明进行了描述,但是,应该理解,本领域技术人员可以设计出很多其他的修改和实施方式,这些修改和实施方式将落在本申请公开的原则范围和精神之内。更具体地说,在本申请公开、附图和权利要求的范围内,可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变型和改进外,对于本领域技术人员来说,其他的用途也将是明显的。
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有引用任何外部专利数据! |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |