一种基于AppCan的适用于HybridAPP开发的MVC框架系统的制作方法

文档序号:12915761阅读:415来源:国知局
一种基于AppCan的适用于HybridAPP开发的MVC框架系统的制作方法与工艺

本发明属于it技术领域,尤其涉及适用于基于appcan框架hybridapp(包括:android、ios等)开发系统。



背景技术:

得益于html5的强大功能和快速发展,hybridapp这些年逐渐火热起来。涌现了各种hybridapp框架,appcan就是国内自主开发的相对比较成功的一个框架。

实际应用中发现该框架存在很多缺陷。首先没有一个固定的页面体系,呈现、逻辑和数据混合在一起,给页面开发带来混乱。其次,插件机制的局限性造成页面调度及进程调度机制混乱。最后,无法按功能、页面划分模块,并进行多人开发管理。造成这样的原因一方面和appcan的针对的目标应用有关,其目标应用以内容展示型为主,对于复杂的业务逻辑并不擅长。另一方面和其发展阶段有关,目前appcan框架还处于逐渐发展阶段。

appcan的hybridapp的依托于js语言实现。不同于java,.net等语言mvc框架众多,js语言非常灵活,框架少,尤其是appcan下的mvc框架几乎没有。



技术实现要素:

针对现有技术存在的问题,本发明提供了一种基于appcan的适用于hybridapp开发的mvc框架系统,实现了入口页面加载整个框架,所有的控制逻辑、业务逻辑、页面逻辑都由本框架处理的功能;同时本发明中将所有的回调路径封装在底层,让每个动作都遵循相同的回调机制,是整个系统逻辑清晰,不会混乱。这样做也便于系统功能的模块化,便于多人分工协作。

为解决上述技术问题,本发明采用了以下技术方案:一种基于appcan的适用于hybridapp开发的mvc框架系统,包括:用于处理业务逻辑的控制器层;用于与数据库进行交互的模型层,用来显示数据并和用户交互的视图层;用于存放包括js、css、图片文件的独立文件夹;以及本框架起始页面index.html,本系统框架的底层机制和逻辑通过basecontroller.js模块和baseview.js模块实现,并由index.html起始页面激发加载。

进一步的,所述视图层存放包括所有页面显示样式和页面逻辑部分对应的文件。

进一步的,所述控制器层保存页面或系统功能对应的所有动作及该动作回调方法。

进一步的,所述模型层存放页面或系统功能的数据处理及业务模型处理。

进一步的,所述basecontroller.js模块用于实现所有其他业务模块的动态加载,并采用工厂模式,所述工厂模式为控制器层仅触发实例化当前使用的动作控制器。

进一步的,所述baseview.js模块主要实现的页面触发的业务时间调用控制层的流程及控制层返回的结果的处理。

有益效果:相对于现有技术,本发明具有以下优点:解决了appcan控制逻辑和回调逻辑混乱问题;解决了appcan控制逻辑、数据逻辑、页面逻辑的分离问题;解决了appcan多人分工协作的问题;解决了appcan代码复用和维护升级问题。

附图说明

图1为本发明所述基于appcan的适用于hybridapp开发的mvc框架系统的框架图;

图2为本发明所述基于appcan的适用于hybridapp开发的mvc框架系统的工作流程图;

图3为本发明所述登录页面在本系统框架运行时调用流程示意图。

具体实施方式

下面结合附图并以具体实施例,进一步阐明本发明。应理解这些实施例仅用于说明本发明而不用于限制本发明的范围,在阅读了本发明之后,本领域技术人员对本发明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。

如图1所示,本发明的基于appcan的适用于hybridapp开发的mvc框架系统,适用于appcanide4.0以上版本的开发环境,并采用mvc模式实现,本框架的目录结构及重要文件的组成包括:

(1)控制器层,用来处理业务逻辑层(对应controller目录);

(2)模型层,用来与数据库进行处理(对应models目录);

(3)视图层,用来显示出数据的层(对应views目录);

所有页面显示样式、页面逻辑部分对应的文件都存放到views目录下。每个页面或系统功能对应的所有动作及该动作的回调方法,一般在一个文件内实现,并放到controller目录下。单个页面或功能的数据处理及业务逻辑处理都存放在做一个models文件内,并存放在models目录下,包括数据库和文件的操作;

(4)html5页面层的js、css、图片等文件单独存放在其他文件夹内;

(5)index.html是appcan加载应用系统的起始页面,也是本框架的起始页面,整个框架的底层机制和逻辑分别在basecontroller.js和baseview.js中实现,这二个文件也是由index.html加载的。

本发明中所有的控制逻辑、业务逻辑、页面逻辑都由本框架处理。必然造成大量的类或实例的加载,消耗巨大的资源不说,appcan本身的回调机制也开始混乱。为解决此问题,本发明定义了一个基础控制页面,在此页面把所有用到的控制器实例工厂化。工厂化即用到哪一个控制器就实例化哪一个控制器,这样即解决插件自身被多次调用造成的混乱,又解决了多人分模块开发,提高效率。

而basecontroller模块中实现了对所有其他业务模块的动态加载,采用的是工厂模式,而不是类似java的继承。baseview中主要实现页面触发的业务时间调用控制层的流程及控制层返回的结果的处理。所有业务处理模块xxmodel.js都继承了basemodel.js。该基础模块中集成了ydcdb模块,ydcdb模块是对数据库操作的封装。

如图2所示,本系统处理流程如下:继承自baseview的页面调用baseview的basecontrollertrigger方法,触发对应的controller内的具体方法,调用对应的model方法,处理业务逻辑,完成后回调对应controller的结果处理方法。对应controller处理完返回结果后,调用basecontroller中的controllerreturn方法,返回到baseview。baseview中调用basecontrollerreturn方法将controller层的处理结果根据view层传递的cb参数返回给对应的veiw页面,触发动作的页面处理动作的返回结果。图中描述了整个框架的执行过程,如果是有页面出发的动作,经过控制器的分发,调用对应的控制器和业务逻辑处理模块,最后将处理结果一级级返回,最终返回到出发动作的地方,完成最终处理。以与底层交互方法为例,对一些重要的方法的实现过程举例:

如图3所示,下面再以典型的登录页面在本系统框架中运行时的调用流程进行说明:例如,在视图层写请求方法与回调方法,实现用户名与密码的登录操作。

本发明借助mvc构架思想,将页面显示、控制逻辑、业务逻辑分离开来,即视图、控制器、模型。要开发出符合此框架的appcan应用,必须解决以下问题:

(1)入口页面加载整个框架。由于本框架在appcan框架之上,所以在appcan的入口页面中加载本框架。本发明定义了一个基础页面index.html,appcan启动时先加载该页面,用于初始化和运行本框架。

(2)在本发明中,所有的控制逻辑、业务逻辑、页面逻辑都由本框架处理。必然造成大量的类或实例的加载,消耗巨大的资源不说,appcan本身的回调机制也开始混乱。为解决此问题,本发明定义了一个基础控制页面,在此页面把所有用到的控制器实例工厂化。工厂化即用到哪一个控制器就实例化哪一个控制器,这样即解决插件自身被多次调用造成的混乱,又解决了多人分模块开发,提高效率。

(3)基础页面加载后,任何一个动作都是由页面或者系统触发的,为了代码的可用性、复用性、可读性,动作在什么地方触发,其结果处理就应该返回到什么地方,这就高度依赖完整的回调机制。本发明中将所有的回调路径封装在底层,让每个动作都遵循相同的回调机制,是整个系统逻辑清晰,不会混乱。这样做也便于系统功能的模块化,便于多人分工协作。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1