CN105956104A - 业务视图框架及其开发方法 - Google Patents

Abstract

本发明实施例公开了一种业务视图框架及其开发方法，所述业务视图框架包括：业务视图层，用于显示业务对应的视图；业务逻辑层，用于根据业务逻辑产生交互数据；其中，所述交互数据用于控制所述业务视图层的数据显示；业务控制层，位于业务视图层和业务逻辑层之间，用于按照交互标准规范，向所述业务视图层和/或所述业务逻辑层传递交互数据。采用本发明的业务视图框架可以减少由于各个层的功能有交叉导致的层与层之间的紧耦合，避免因为紧耦合各个层的开发不能独立进行导致的开发效率低及开发周期长等问题。

Description

业务视图框架及其开发方法

技术领域

本发明涉及网络技术领域，尤其涉及一种业务视图框架及其开发方法。

背景技术

HTML是一门很好的为静态文本展示设计的声明式语言，但要构建网络WEB应用的话它就显得乏力了。通常，我们是通过以下技术来解决静态网页技术在构建动态应用上的不足：类库-类库是一些函数的集合，它能帮助你写WEB应用，其中起主导作用的是代码，由你来决定何时使用类库，类库有：jQuery等；框架-框架是一种特殊的、已经实现了的WEB应用，你只需要对它填充具体的业务逻辑，这里框架是起主导作用的，由框架来根据具体的应用逻辑来调用你的代码，框架有：EXTJS、EasyUI等。

在现有的业务视图框架中，业务视图层和业务控制层是紧耦合层，业务控制层与业务视图层进行的数据交互，这种紧耦合的处理，导致一些图形渲染等操作处理有很多种，导致开发过程中业务视图层的开发会影响业务控制层，业务控制层的开发也会反过来影响业务视图层的开发，导致开发效率低及周期长。

发明内容

有鉴于此，本发明实施例提供一种业务视图框架及其开发方法，以解决业务视图框架各个层之间紧耦合导致的问题。

本发明实施例的技术方案是这样实现的：

本发明实施例提供一种业务视图框架，包括：

业务视图层，用于显示业务对应的视图；

业务逻辑层，用于根据业务逻辑产生交互数据；其中，所述交互数据用于控制所述业务视图层的数据显示；

业务控制层，位于业务视图层和业务逻辑层之间，用于按照交互标准规范，向所述业务视图层和/或所述业务逻辑层传递交互数据。

基于上述方案，所述业务视图框架包括：视图模板；

所述视图模板包括所述业务视图层及与每一个所述业务视图层对应的脚本文件库；

其中，所述脚本文件库能够用于存储操作对应业务视图层的脚本文件。

基于上述方案，每一个所述业务视图层单独对应的脚本文件库，能够用于基于操作指示，修改位于所述脚本文件库中的脚本文件。

基于上述方案，所述业务视图框架还包括网络工程；

所述网络工程包括各所述业务视图层共用的基本脚本文件。

基于上述方案，所述基本脚本文件包括类库脚本文件；

所述类库脚本文件包括表格转换函数；

所述表格转换函数能够用于使第一类型表格转换成第二类型表格。

本发明实施例第二方面提供一种业务视图框架开发方法，包括：

根据业务逻辑，分别独立开发业务逻辑层及业务视图层；其中，所述业务视图层用于显示业务对应的视图；所述业务逻辑层，用于根据业务逻辑产生交互数据；其中，所述交互数据用于控制所述业务视图层的数据显示；

根据交互标准规范，开发业务控制层；其中，所述业务逻辑层用于按照交互标准规范，向所述业务视图层和/或所述业务逻辑层传递所述交互数据。

基于上述方案，所述方法还包括：

为每一个所述业务视图层单独配置对应的脚本文件库；

其中，所述脚本文件库能够用于存储操作对应业务视图层的脚本文件。

基于上述方案，所述为每一个所述业务视图层单独配置对应的脚本文件库，包括：

接收操作指示；

基于操作指示，修改位于所述脚本文件库中的脚本文件。

基于上述方案，所述方法还包括：

配置各所述所述业务视图层共用的基本脚本文件。

基于上述方案，所述基本脚本文件包括类库脚本文件；

所述方法还包括：

在所述类库文件中设置表格转换函数；

其中，所述表格转换函数能够用于使第一类型表格转换成第二类型表格。

本发明实施例提供的业务视图框架及其开发方法，业务视图框架包括业务视图层、业务逻辑层及业务控制层，三个层的功能划分明确且在进行数据交互时，按照统一的交互标准规范进行，这样可以减少由于各个层的功能有交叉导致的层与层之间的紧耦合，避免因为紧耦合各个层的开发不能独立进行导致的开发效率低及开发周期长等问题。

附图说明

图1为实现本发明各个实施例的一个可选的移动终端100的硬件结构示意图；

图2为如图1所示的移动终端100的无线通信系统示意图；

图3为本发明提供的一种业务视图框架的结构示意图；

图4为本发明实施例提供的一种业务视图框架开发流程示意图；

图5为本发明实施例提供的另一种业务视图框架开发流程示意图；

图6至图8为基于本发明实施例所述业务视图框架的显示效果示意图；

图9为本发明实施例提供的js文件架构的示意图；

图10为本发明实施例提供的业务视图框架的应用流程示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明的技术方案，并不用于限定本发明的保护范围。

现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

移动终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、个人数字助理(PDA)、平板电脑(PAD)、便携式多媒体播放器(PMP)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是移动终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例的移动终端100的硬件结构示意，如图1所示，移动终端100可以包括无线通信单元110、音频/视频(A/V)输入单元120、用户输入单元130、感测单元140、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的移动终端100，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述移动终端100的元件。

无线通信单元110通常包括一个或多个组件，其允许移动终端100与无线通信系统或网络之间的无线电通信。例如，无线通信单元110可以包括广播接收模块111、移动通信模块112、无线互联网模块113、短程通信模块114和位置信息模块115中的至少一个。

广播接收模块111经由广播信道从外部广播管理服务器接收广播信号和/或广播相关信息。广播信道可以包括卫星信道和/或地面信道。广播管理服务器可以是生成并发送广播信号和/或广播相关信息的服务器或者接收之前生成的广播信号和/或广播相关信息并且将其发送给终端的服务器。广播信号可以包括TV广播信号、无线电广播信号、数据广播信号等等。而且，广播信号可以进一步包括与TV或无线电广播信号组合的广播信号。广播相关信息也可以经由移动通信网络提供，并且在该情况下，广播相关信息可以由移动通信模块112来接收。广播信号可以以各种形式存在，例如，其可以以数字多媒体广播(DMB)的电子节目指南(EPG)、数字视频广播手持(DVB-H)的电子服务指南(ESG)等等的形式而存在。广播接收模块111可以通过使用各种类型的广播系统接收信号广播。特别地，广播接收模块111可以通过使用诸如多媒体广播-地面(DMB-T)、数字多媒体广播-卫星(DMB-S)、数字视频广播-手持(DVB-H)，前向链路媒体(MediaFLO^@)的数据广播系统、地面数字广播综合服务(ISDB-T)等等的数字广播系统接收数字广播。广播接收模块111可以被构造为适合提供广播信号的各种广播系统以及上述数字广播系统。经由广播接收模块111接收的广播信号和/或广播相关信息可以存储在存储器160(或者其它类型的存储介质)中。

移动通信模块112将无线电信号发送到基站(例如，接入点、节点B等等)、外部终端以及服务器中的至少一个和/或从其接收无线电信号。这样的无线电信号可以包括语音通话信号、视频通话信号、或者根据文本和/或多媒体消息发送和/或接收的各种类型的数据。

无线互联网模块113支持移动终端100的无线互联网接入。无线互联网模块113可以内部或外部地耦接到终端。无线互联网模块113所涉及的无线互联网接入技术可以包括无线局域网(WLAN)、无线相容性认证(Wi-Fi)、无线宽带(Wibro)、全球微波互联接入(Wimax)、高速下行链路分组接入(HSDPA)等等。

短程通信模块114是用于支持短程通信的模块。短程通信技术的一些示例包括蓝牙^TM、射频识别(RFID)、红外数据协会(IrDA)、超宽带(UWB)、紫蜂^TM等等。

位置信息模块115是用于检查或获取移动终端100的位置信息的模块。位置信息模块115的典型示例是全球定位系统(GPS)模块115。根据当前的技术，GPS模块115计算来自三个或更多卫星的距离信息和准确的时间信息并且对于计算的信息应用三角测量法，从而根据经度、纬度和高度准确地计算三维当前位置信息。当前，用于计算位置和时间信息的方法使用三颗卫星并且通过使用另外的一颗卫星校正计算出的位置和时间信息的误差。此外，GPS模块115能够通过实时地连续计算当前位置信息来计算速度信息。

A/V输入单元120用于接收音频或视频信号。A/V输入单元120可以包括相机121和麦克风122，相机121对在视频捕获模式或图像捕获模式中由图像捕获装置获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元151上。经相机121处理后的图像帧可以存储在存储器160(或其它存储介质)中或者经由无线通信单元110进行发送，可以根据移动终端100的构造提供两个或更多相机121。麦克风122可以在电话通话模式、记录模式、语音识别模式等等运行模式中经由麦克风接收声音(音频数据)，并且能够将这样的声音处理为音频数据。处理后的音频(语音)数据可以在电话通话模式的情况下转换为可经由移动通信模块112发送到移动通信基站的格式输出。麦克风122可以实施各种类型的噪声消除(或抑制)算法以消除(或抑制)在接收和发送音频信号的过程中产生的噪声或者干扰。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制移动终端100的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示单元151上时，可以形成触摸屏。

感测单元140检测移动终端100的当前状态，(例如，移动终端100的打开或关闭状态)、移动终端100的位置、用户对于移动终端100的接触(即，触摸输入)的有无、移动终端100的取向、移动终端100的加速或减速移动和方向等等，并且生成用于控制移动终端100的操作的命令或信号。例如，当移动终端100实施为滑动型移动电话时，感测单元140可以感测该滑动型电话是打开还是关闭。另外，感测单元140能够检测电源单元190是否提供电力或者接口单元170是否与外部装置耦接。

接口单元170用作至少一个外部装置与移动终端100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口(典型示例是通用串行总线USB端口)、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。识别模块可以是存储用于验证用户使用移动终端100的各种信息并且可以包括用户识别模块(UIM)、客户识别模块(SIM)、通用客户识别模块(USIM)等等。另外，具有识别模块的装置(下面称为“识别装置”)可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与移动终端100连接。

接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端100和外部装置之间传输数据。

另外，当移动终端100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到移动终端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到移动终端100的路径。从底座输入的各种命令信号或电力可以用作用于识别移动终端100是否准确地安装在底座上的信号。

输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。输出单元150可以包括显示单元151、音频输出模块152、警报单元153等等。

显示单元151可以显示在移动终端100中处理的信息。例如，当移动终端100处于电话通话模式时，显示单元151可以显示与通话或其它通信(例如，文本消息收发、多媒体文件下载等等)相关的用户界面(UI)或图形用户界面(GUI)。当移动终端100处于视频通话模式或者图像捕获模式时，显示单元151可以显示捕获的图像和/或接收的图像、示出视频或图像以及相关功能的UI或GUI等等。

同时，当显示单元151和触摸板以层的形式彼此叠加以形成触摸屏时，显示单元151可以用作输入装置和输出装置。显示单元151可以包括液晶显示器(LCD)、薄膜晶体管LCD(TFT-LCD)、有机发光二极管(OLED)显示器、柔性显示器、三维(3D)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为TOLED(透明有机发光二极管)显示器等等。根据特定想要的实施方式，移动终端100可以包括两个或更多显示单元(或其它显示装置)，例如，移动终端100可以包括外部显示单元(未示出)和内部显示单元(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积。

音频输出模块152可以在移动终端100处于呼叫信号接收模式、通话模式、记录模式、语音识别模式、广播接收模式等等模式下时，将无线通信单元110接收的或者在存储器160中存储的音频数据转换音频信号并且输出为声音。而且，音频输出模块152可以提供与移动终端100执行的特定功能相关的音频输出(例如，呼叫信号接收声音、消息接收声音等等)。音频输出模块152可以包括扬声器、蜂鸣器等等。

警报单元153可以提供输出以将事件的发生通知给移动终端100。典型的事件可以包括呼叫接收、消息接收、键信号输入、触摸输入等等。除了音频或视频输出之外，警报单元153可以以不同的方式提供输出以通知事件的发生。例如，警报单元153可以以振动的形式提供输出，当接收到呼叫、消息或一些其它进入通信(incoming communication)时，警报单元153可以提供触觉输出(即，振动)以将其通知给用户。通过提供这样的触觉输出，即使在用户的移动电话处于用户的口袋中时，用户也能够识别出各种事件的发生。警报单元153也可以经由显示单元151或音频输出模块152提供通知事件的发生的输出。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储已经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，移动终端100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制移动终端100的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。另外，控制器180可以包括用于再现或回放多媒体数据的多媒体模块181，多媒体模块181可以构造在控制器180内，或者可以构造为与控制器180分离。控制器180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。

电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

至此，已经按照其功能描述了移动终端100。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型移动终端100等等的各种类型的移动终端100中的滑动型移动终端100作为示例。因此，本发明能够应用于任何类型的移动终端100，并且不限于滑动型移动终端100。

如图1中所示的移动终端100可以被构造为利用经由帧或分组发送数据的诸如有线和无线通信系统以及基于卫星的通信系统来操作。

现在将参考图2描述其中根据本发明的移动终端100能够操作的通信系统。

这样的通信系统可以使用不同的空中接口和/或物理层。例如，由通信系统使用的空中接口包括例如频分多址(FDMA)、时分多址(TDMA)、码分多址(CDMA)和通用移动通信系统(UMTS)(特别地，长期演进(LTE))、全球移动通信系统(GSM)等等。作为非限制性示例，下面的描述涉及CDMA通信系统，但是这样的教导同样适用于其它类型的系统。

参考图2，CDMA无线通信系统可以包括多个移动终端100、多个基站(BS)270、基站控制器(BSC)275和移动交换中心(MSC)280。MSC 280被构造为与公共电话交换网络(PSTN)290形成接口。MSC 280还被构造为与可以经由回程线路耦接到基站270的BSC 275形成接口。回程线路可以根据若干己知的接口中的任一种来构造，所述接口包括例如E1/T1、ATM、IP、PPP、帧中继、HDSL、ADSL或xDSL。将理解的是，如图2中所示的系统可以包括多个BSC2750。

每个BS 270可以服务一个或多个分区(或区域)，由多向天线或指向特定方向的天线覆盖的每个分区放射状地远离BS 270。或者，每个分区可以由用于分集接收的两个或更多天线覆盖。每个BS 270可以被构造为支持多个频率分配，并且每个频率分配具有特定频谱(例如，1.25MHz，5MHz等等)。

分区与频率分配的交叉可以被称为CDMA信道。BS 270也可以被称为基站收发器子系统(BTS)或者其它等效术语。在这样的情况下，术语“基站”可以用于笼统地表示单个BSC 275和至少一个BS 270。基站也可以被称为“蜂窝站”。或者，特定BS 270的各分区可以被称为多个蜂窝站。

如图2中所示，广播发射器(BT)295将广播信号发送给在系统内操作的移动终端100。如图1中所示的广播接收模块111被设置在移动终端100处以接收由BT295发送的广播信号。在图2中，示出了几个卫星300，例如可以采用全球定位系统(GPS)卫星300。卫星300帮助定位多个移动终端100中的至少一个。

在图2中，描绘了多个卫星300，但是理解的是，可以利用任何数目的卫星获得有用的定位信息。如图1中所示的GPS模块115通常被构造为与卫星300配合以获得想要的定位信息。替代GPS跟踪技术或者在GPS跟踪技术之外，可以使用可以跟踪移动终端100的位置的其它技术。另外，至少一个GPS卫星300可以选择性地或者额外地处理卫星DMB传输。

作为无线通信系统的一个典型操作，BS 270接收来自各种移动终端100的反向链路信号。移动终端100通常参与通话、消息收发和其它类型的通信。特定基站270接收的每个反向链路信号被在特定BS 270内进行处理。获得的数据被转发给相关的BSC 275。BSC提供通话资源分配和包括BS 270之间的软切换过程的协调的移动管理功能。BSC275还将接收到的数据路由到MSC 280，其提供用于与PSTN 290形成接口的额外的路由服务。类似地，PSTN 290与MSC280形成接口，MSC与BSC 275形成接口，并且BSC 275相应地控制BS 270以将正向链路信号发送到移动终端100。

移动终端中无线通信单元110的移动通信模块112基于移动终端内置的接入移动通信网络(如2G/3G/4G等移动通信网络)的必要数据(包括用户识别信息和鉴权信息)接入移动通信网络为移动终端用户的网页浏览、网络多媒体播放等业务传输移动通信数据(包括上行的移动通信数据和下行的移动通信数据)。

无线通信单元110的无线互联网模块113通过运行无线热点的相关协议功能而实现无线热点的功能，无线热点支持多个移动终端(移动终端之外的任意移动终端)接入，通过复用移动通信模块112与移动通信网络之间的移动通信连接为移动终端用户的网页浏览、网络多媒体播放等业务传输移动通信数据(包括上行的移动通信数据和下行的移动通信数据)，由于移动终端实质上是复用移动终端与通信网络之间的移动通信连接传输移动通信数据的，因此移动终端消耗的移动通信数据的流量由通信网络侧的计费实体计入移动终端的通信资费，从而消耗移动终端签约使用的通信资费中包括的移动通信数据的数据流量。

基于上述移动终端100硬件结构以及通信系统，提出本发明方法各个实施例。

如图3所示，本发明实施例提供一种业务视图框架，包括：

业务视图层310，用于显示业务对应的视图；

业务逻辑层320，用于根据业务逻辑产生交互数据；其中，所述交互数据用于控制所述业务视图层310的数据显示；

业务控制层330，位于业务视图层和业务逻辑层之间，用于按照交互标准规范，向所述业务视图层和/或所述业务逻辑层传递交互数据。

本实施例提供一种业务视图框架，该业务视图框架包括了业务视图层310、业务逻辑层320、和业务控制层330。业务视图层310、业务逻辑层320和业务控制层330都有是相对独立层；各个层之间的功能都很明确，相互是松耦合的状态，这样方便独立开发各个层，这样可以减少在开发过程中各个层之间的限制，提高开发效率。

在本实施例中业务控制层330相当于标准的传输接口，所述业务视图层310仅负责视图的展示，业务逻辑层320根据业务逻辑提供交互数据，该交互数据控制业务视图层310的视图显示。

在具体的实现过程中，所述业务视图层310还用于接收用户指示，根据所述用户指示通过所述业务控制层320向所述业务逻辑层330发送请求指示；所述业务逻辑层330具体可用于响应所述请求指示，根据业务逻辑生成所述交互数据，并通过所述业务控制层320向所述业务视图层310传输所述交互数据，这些交互数据将控制所述业务视图层310的视图渲染等视图显示操作。

这样就避免了如现有技术中仅有业务控制层和业务视图层这种仅耦合架构，且避业务控制层与不同业务视图层之间进行数据交互遵循的标准不一致导致交互规则，导致的业务视图层310和业务控制层330在开发过程中的相互制肘，导致的开发不方便及开发效率低的问题。

在本实施例中增加了业务逻辑层320负责产生交互数据，业务控制层330仅负责传递数据，业务视图层310仅负载显示就好，各个层实现的功能划分明确，且交互过程采用统一的交互标准贵发，这样就能够实现各个层之间的松散架构，避免开发过程中的相互制约，提升开发效率。

在本实施例中所述前端康佳可以为模型-视图-控制(Model View-Controller,MVC)框架。所述交互数据可为JSON格式的JSON数据。所述JSON为JavaScriptObject Notation的缩写，是一种轻量级的数据换格式。所述业务控制层330之间按照JSON格式在业务逻辑层320与各个业务视图层310之间统一进行JSON数据的交互。

进一步地，

所述业务视图框架包括：视图模板；

所述视图模板包括所述业务视图层310及与每一个所述业务视图层310对应的脚本文件库；其中，所述脚本文件库能够用于存储控制对应业务视图层310显示的脚本文件。

在本实施例中所述视图模板，所述业务视图层310为视图模板的组成部分。在所述视图模板中还单独为每一个所述业务视图层310单独设置了脚本文件库，例如，业务视图层A对应的脚本文件库A中的脚本文件都是用于修改业务视图层A的各种操作的文件。在本实施例中所述脚本文件可包括各种程序的脚本文件，例如，Java的脚本(JavaScript，js)文件。

这样的话，若需要对某一个业务视图层进行修改，仅需修改该业务视图层对应的脚本文件库即可，不会对干扰业务视图层，这样就增加了业务视图层修改和操作的灵活性。例如，不同的开发人员可以根据自己需求，单独给出执行一些特殊操作的脚本文件，将这些脚本文件增加到脚本文件库中，方便丰富业务视图层的显示。例如，开发人员可以增加一键换肤的脚本文件，这样可以将该脚本文件添加到对应的业务视图层的脚本文件库中，这样后续就可以对该业务视图层进行一键换肤的工作，从而给用户不同的显示风格体验，提高显示智能性及用户使用满意度。显然，这样的业务视图层310的界面显示修改灵活性大，可扩展性大。

进一步地，每一个所述业务视图层310单独对应的脚本文件库，能够用于基于操作指示，修改位于所述脚本文件库中的脚本文件。在本实施例中所述操作指示可为开发人员或用户人员输入的操作。在本实施例中所述脚本文件库内的脚本文件可以增加、删除、修改、查询及更新。

进一步地，所述业务视图框架还包括网络工程；

所述网络工程包括各所述业务视图层310共用的基本脚本文件。

在本实施例中所述网络工程存储有各个业务视图层共用的基本脚本文件。所述基本脚本文件通常是支撑业务视图层310运行的基本功能的脚本文件，例如，类库脚本文件。在本实施例中所述基本脚本文件可为指定类型的通常不建议用户修改的脚本文件。总之本实施例一个业务视图层310对应的脚本文件分为两大类，一类为基本脚本文件，另一类为脚本文件库中可以操作的脚本文件。通常基本脚本文件不同于脚本文件库中的脚本文件。通过所有业务视图层310共用基本脚本文件可以减少业务视图框架的数据冗余，通过为每一个业务视图层310设置脚本文件库，可以实现不同业务视图层310显示的不同需求和特点。

例如，当所述网络工程为Java语言的网络工程时，所述基本脚本文件可以包括以下文件：

类库js文件，例如，Jquery.min.js，用于执行业务框架的基本功能，这里的基本功能可包括进行业务逻辑层和业务视图层之间的数据交互、执行选择器的选择工呢过、确定视图显示位置的定位功能、确定视图显示风格的控制功能及事件处理功能。这里的视图显示风格可包括颜色、字体的选择等。所述事件处理功能可包括鼠标悬停等各种输入事件和输出事件。

表格插件js文件，例如，Jquery.dataTables.min.js，用于控制表格显示。

树插件js文件，例如，Jquery.treetable.js，用于控制树形表格显示。

表单验证插件js文件，例如，Jquery.validate.min.js，用于进行表单的有效性验证，这里的有效性验证包括验证表单内数据的真实性和/或合法性。

预留封装的用户标识类库js文件，例如，Jquery.nUI.min.js，用于执行对应的自定义功能。

上述5个js文件都是各个业务视图层310常用到的脚本文件，且一般很少修改，在本实施例中为了减少业务视图框架的代码的数据量，在本实施例中由所有业务视图层310共用基本脚本文件，以减少数据冗余，精简业务视图框架。在本实施例中为了实现利用同一个数据源形成不同类型的表格，在本实施例中在所述基本脚本文件包括的类库脚本文件中表格转换函数。所述表格转换函数能够用于使第一类型表格转换成第二类型表格。这样方便开发人员或不同的用户，利用同一数据源控制所述业务视图层以不同类型的表格进行展示。

例如，可通过调用所述类库脚本文件中的表格转换函数可以将普通的行列式表格，转换成树形表格。

总之，本实施例提供了一种业务视图框架，在业务视图层310和业务逻辑层330之间，设置了业务控制层320，通过业务控制层320按照交互标准规范进行数据传输，实现了多个层之间的松耦合，避免紧耦合导致的开发相互牵连，开发时间周期长等问题。

实施例二：

如图4所示，本实施例提供一种业务视图框架开发方法，包括：

步骤S110：根据业务逻辑，分别独立开发业务逻辑层及业务视图层；其中，所述业务视图层用于显示业务对应的视图；所述业务逻辑层，用于根据业务逻辑产生交互数据；其中，所述交互数据用于控制所述业务视图层的数据显示；

步骤S120：根据交互标准规范，开发业务控制层；其中，所述业务逻辑层用于按照交互标准规范，向所述业务视图层和/或所述业务逻辑层传递所述交互数据。

在本实施例中提供的为实施例一中所述的业务视图框架的开发方法，值得注意的是：步骤S110和步骤S120没有一定的先后关系，可以先执行步骤S110，再执行步骤S120，也可以先执行步骤S120，再执行步骤S110；也可以同时执行步骤S110和步骤S120。由于业务视图层、业务逻辑层和业务控制层之间是松耦合的关系，可以分别独立开发；且由于各个层的功能划分明确，业务逻辑层与各个业务视图层之间的交互都由业务控制层采用统一的交互标准规范进行，这样开发出的业务视图框架，可以避免现有技术中的业务视图框架的逻辑混乱及功能混乱导致的功能不稳定的现象。

进一步地，所述方法还包括：

为每一个所述业务视图层单独配置对应的脚本文件库；其中，所述脚本文件库能够用于存储操作对应业务视图层的脚本文件。

在本实施例中单独为每一个业务视图层都设置了脚本文件库，该脚本文件库中存储了操作该业务视图层的脚本文件。这样如果有需要对某一个业务对应的业务视图层进行修改，直接可以通过修改该业务视图层对应的脚本文件库中的脚本文件，就能够灵活的修改该业务视图层。

在本实施例中为了方便对每一个业务对应的业务视图层进行单独修改，在本实施例中为每一个业务视图层单独配置了对应的脚本文件库，这样方便对不同的业务进行业务视图层的灵活和单独修改，避免了现有技术中多个业务视图层共用所有脚本文件，导致的业务视图层一旦开发完毕修改困难的问题。

具体地，所述为每一个所述业务视图层单独配置对应的脚本文件库，包括：

接收操作指示；

基于操作指示，修改位于所述脚本文件库中的脚本文件。在本实施例中素数操作指示可包括增加指示、删除指示、修改指示、查询指示或更新指示等其中的一个或多个，根据这些指示对对应业务视图层的脚本文件库中的脚本文件进行增删、修改、更新及查询等操作，具有操作简单、可扩展性高及灵活性大等问题。

此外，所述方法还包括：配置各所述所述业务视图层共用的基本脚本文件。

在本实施例中所述基本脚本文件通常为业务视图层的显示提供基本代码支持。在本实施例中所述基本脚本文件可以参见实施例一中的举例，在此就不再一一详细描述了，通过不同业务视图层的共用基本脚本文件，可以减少代码的数据量，减少业务视图框架的数据冗余。

进一步地，所述基本脚本文件包括类库脚本文件；所述方法还包括：在所述类库文件中设置表格转换函数；其中，所述表格转换函数能够用于使第一类型表格转换成第二类型表格。

在本实施例中所述基本脚本文件包括的类库脚本文件中设置有表格转换函数，可以通过不同所述表格转换函数，使用一个数据源呈现出不同类型的表格，满足不同类型表格的呈现需求。

以下结合上述实施例提供几个具体示例：

如图5所示，本示例基于上述任意一个方法，基于java语言提供一种业务视图框架开发方法，包括：

步骤S1、框架搭建，包括：搭建基础的网络WEB工程，并在WEB工程引入需要用到的组合类库，所述组合类库可包括以下脚本文件。

Jquery.min.js：js类库

Jquery.dataTables.min.js：表格插件

Jquery.treetable.js：树插件

Jquery.validate.min.js：表单验证插件

Jquery.nUI.min.js：自己封装的ui类库

五个js文件总共加起来不到200KB，易于部署。

步骤S2、模板定制，可包括：

步骤S201.前端创建对应的业务视图层，业务视图层可简称V层。

步骤S202.基于文件对象模型(Document Object Model，DOM)的模板渲染，创建一个图层(Dvision，DIV)，简化了js文件的常用操作。

步骤S203.为每个业务视图层对应单独设置js文件，例如可包括：增加、修改、删除、查询总共四个js文件。

步骤S3、MVC严格分层设置，具体可包括：

步骤S301.后端创建对应的业务控制层，该业务控制层简称为C层。

步骤S302.C层不做任何渲染，只传递JSON数据给前端的V层或向后端的业务逻辑层传输数据。因为JSON数据便于读取和解析，在某层意义上说，C层只负责接收和传递JSON数据。通常JSON数据是由业务逻辑层产生的。通常所述业务逻辑层简称M层。

在完成步骤S1～S3后，本方案的配置部分已经基本完成。在同一个业务中，除了使用表格外，某些时候还需要把表格渲染成树型表格，这个时候需要对组件的重用和优先利用了。

步骤S4,、组件重用，可包括：

通过Jquery.nUI.min.js文件封装对数据表格dataTables的整套使用，其中就包括增加、修改、删除、查询的js封装处理，在事件列表中引入树形表格treetable的数据渲染，形成树形表格展示给前端。两者既不冲突，并且能高效的优先运行。

本示例提供的业务视图框架，能够简便的利用C层的JSON数据交互，提高了V层和M层的读写性能，可支持多种数据源的操作，例如DOM、AJAX、JAVASCRIPT、服务器处理等。图6为本示例提供的一种业务视图层的显示示意图。图7为本实施例提供的一种新增视图的效果示意图。

本示例体统的业务视图框架还具有良好的测试性能，

一个项目在研发过程当中，注重的是开发的质量，此业务视图框架提供了良好的可测试性，一个业务模块在编写结束后，既可以在框架中进行模拟测试，同样的也可以在浏览器中通过URL直接测试自己想要的结果。对于BUG很容易定位，易于维护，减少了项目的维护成本。结合有效表单验证，循环校验业务正确性，然后一次性渲染。图8为本示例提供的另一种新增业务视图的显示效果图。

此外，本示例提供的业务视图框架可单独为每一个业务对应的业务视图层设置js文件，当用户需要可以灵活的向该业务视图层引入其他js文件，或修改该业务视图层对应的js文件，从而是实现对该业务视图层实现增、删、改、查询和界面风格的操作；且额外引入该业务视图层的js文件不会与其他业务层的显示产生冲突。

如图9所示，用户可以利用js文件提出操作请求，这样前端的业务视图层就能够接收到，并通过业务控制层传输给后端的业务逻辑层。在图9所示的js文件类型中包括库类js文件、自定义js文件、验证js文件及数据表格js文件等。所述数据表格js文件又包括树形表格js文件。

图10所示的为基于本发明实施例提供的业务视图框架的的一个应用示例，包括：

步骤S111：启动应用；

步骤S112：加载系统自带js文件，这里的系统自带js文件可包括前述的基本脚本文件和每一个业务视图层系统自带的js文件。

步骤S113：加载自定义js文件。

上述步骤S111至步骤S113都可视为步骤S11的具体执行步骤。

步骤S12：将上述js文件装载到容器中，这里的容器可包括iframe等容器。

步骤S13：判断装置是否成功，若是进入步骤S14，若否，则停止流程。

步骤S14：加载数据表格列表组件，这里的数据表格列表组件为前述js文件的一种。

步骤S15：获取交互数据，例如，通过业务控制层从业务逻辑层获取JSON数据。

步骤S16：视图加载。

步骤S17：对象抽象化，这里的对象抽象化可包括在步骤S16中基于用户指示或应用的内置指令确定了加载视图之后，对获取的交互数据进行对象抽象画，生成可执行代码。

步骤S18：判断渲染是否成功，具体可包括：利用生成的可执行代码进行渲染，若是，则进入步骤S19：若否则停止该流程。

步骤S19：基于可执行代码创建实例，这里的实例可为视图的一个具体例子，例如创建表格。

步骤S20：校验，可包括对填入到实例中的数据进行校验。该数据可为交互数据的部分或基于交互数据产生的数据。

步骤S21：模板展示，在模板中展示创建的实例，实例中所填充的数据为通过校验的数据。

步骤S22：加载树形表格，可包括：当基于用户指示或基于应用内置指令确定展示树形表格时，加载树形表格。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种业务视图框架，其特征在于，包括：

业务视图层，用于显示业务对应的视图；

业务逻辑层，用于根据业务逻辑产生交互数据；其中，所述交互数据用于控制所述业务视图层的数据显示；

业务控制层，位于业务视图层和业务逻辑层之间，用于按照交互标准规范，向所述业务视图层和/或所述业务逻辑层传递交互数据。

2.根据权利要求1所述的业务视图框架，其特征在于，

所述业务视图框架包括：视图模板；

所述视图模板包括所述业务视图层及与每一个所述业务视图层对应的脚本文件库；

其中，所述脚本文件库能够用于存储操作对应业务视图层的脚本文件。

3.根据权利要求2所述的业务视图框架，其特征在于，

每一个所述业务视图层单独对应的脚本文件库，能够用于基于操作指示，修改位于所述脚本文件库中的脚本文件。

4.根据权利要求1所述的业务视图框架，其特征在于，

所述业务视图框架还包括网络工程；

所述网络工程包括各所述业务视图层共用的基本脚本文件。

5.根据权利要求4所述的业务视图框架，其特征在于，

所述基本脚本文件包括类库脚本文件；

所述类库脚本文件包括表格转换函数；

所述表格转换函数能够用于使第一类型表格转换成第二类型表格。

6.一种业务视图框架开发方法，其特征在于，包括：

根据业务逻辑，分别独立开发业务逻辑层及业务视图层；其中，所述业务视图层用于显示业务对应的视图；所述业务逻辑层，用于根据业务逻辑产生交互数据；其中，所述交互数据用于控制所述业务视图层的数据显示；

根据交互标准规范，开发业务控制层；其中，所述业务逻辑层用于按照交互标准规范，向所述业务视图层和/或所述业务逻辑层传递所述交互数据。

7.根据权利要求6所述的方法，其特征在于，

所述方法还包括：

为每一个所述业务视图层单独配置对应的脚本文件库；

其中，所述脚本文件库能够用于存储操作对应业务视图层的脚本文件。

8.根据权利要求7所述的方法，其特征在于，

所述为每一个所述业务视图层单独配置对应的脚本文件库，包括：

接收操作指示；

基于操作指示，修改位于所述脚本文件库中的脚本文件。

9.根据权利要求6所述的方法，其特征在于，

所述方法还包括：

配置各所述所述业务视图层共用的基本脚本文件。

10.根据权利要求4所述的方法，其特征在于，

所述基本脚本文件包括类库脚本文件；

所述方法还包括：

在所述类库文件中设置表格转换函数；

其中，所述表格转换函数能够用于使第一类型表格转换成第二类型表格。