CN111399943B - 数据处理的方法、装置、存储介质和电子装置 - Google Patents

Abstract

本发明公开了一种数据处理的方法、装置、存储介质和电子装置。该方法包括：获取目标应用的逻辑业务层的待处理数据，并将待处理数据发送至数据访问层；在配置有目标插件的数据访问层中，基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果，其中，目标插件为基于Rails引擎生成的且包含目标应用与其关联应用的公用数据访问层数据的插件；基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。通过本发明，达到了提高应用中的数据处理效率的效果。

Description

数据处理的方法、装置、存储介质和电子装置

技术领域

本发明涉及数据处理领域，具体而言，涉及一种数据处理的方法、装置、存储介质和电子装置。

背景技术

当前互联网的入口较多，如，个人计算机(Personal Computer，简称为PC)端、移动端等。故一个网页(WEB)应用为了满足用户不同场景的操作需求，一般会针对不同的入口开发不同的应用项目，譬如电商系统通常包含商家管理后台项目、PC端用户购物项目、触屏版用户购物项目等。每个应用项目都包含各自的一套数据访问层和业务逻辑层，带来很多代码、逻辑及文件的重用的问题。另外一种方法是将多个应用混合成一个整体，但该方法将各种不相关的逻辑混合于一起，会导致应用日渐臃肿，进而难以扩展。

以上的方案都加剧了应用开发的复杂性，也加大了后续维护流程上的人力及时间成本，从而导致对应用的数据处理效率低的问题。

针对现有技术中对应用的数据处理效率低的问题，目前尚未提出有效的解决方案。

发明内容

本发明的主要目的在于提供一种数据处理的方法、装置、存储介质和电子装置，以至少解决对应用的数据处理效率低的技术问题。

为了实现上述目的，根据本发明的一个方面，提供了一种数据处理的方法。该方法可以包括：获取目标应用的逻辑业务层的待处理数据，并将待处理数据发送至数据访问层；在配置有目标插件的数据访问层中，基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果，其中，目标插件为基于Raisl引擎生成的且包含目标应用与其关联应用的公用数据访问层数据的插件；基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。

可选地，目标插件中还包含Gem包。

可选地，基于目标插件对待处理数据进行数据访问处理，包括：基于目标插件预先设置的自动加载属性，在目标插件中加载第一结构目录。

可选地，该方法还包括：基于目标插件对待处理数据进行数据访问处理之前，包括：判断当前的处理环境是否为线上环境；若当前的处理环境是线下环境，则基于目标应用中存储的本地路径获取目标插件；若当前的处理环境是线上环境，则基于目标应用中存储的远程地址获取目标插件。

可选地，本地路径存储于目标应用的development组中，远程地址存储于目标应用的production组中。

可选地，基于目标插件对待处理数据进行数据访问处理，包括：加载目标应用对应的补丁文件和目标插件，补丁文件包含目标应用与其关联应用相差异的数据；基于目标插件和补丁文件对待处理数据进行数据访问处理。

可选地，加载目标应用对应的补丁文件和目标插件，包括：根据目标应用的配置文件自动加载目标应用对应的补丁文件和目标插件。

可选地，基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互包括：将目标应用的数据访问处理结果写入数据库中；或者，通过目标应用的数据访问处理结果从数据库中读取对应的目标数据

可选地，目标应用为Rails应用，目标插件为Rails引擎。

为了实现上述目的，根据本发明的另一方面，还提供了另一种数据处理的方法。该方法包括：获取单元，用于获取目标应用的逻辑业务层的待处理数据，并将待处理数据发送至数据访问层；处理单元，用于在配置有目标插件的数据访问层中，基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果，其中，目标插件为基于Raisl引擎生成的且包含目标应用与其关联应用的公用数据访问层数据的插件；交互单元，用于基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。

为了实现上述目的，根据本发明的另一方面，提供了一种存储介质。该存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行本发明实施例的数据处理的方法。

为了实现上述目的，根据本发明的另一方面，提供了一种电子装置。该电子装置包括存储器和处理器，其特征在于，存储器中存储有计算机程序，处理器被设置为运行计算机程序以执行本发明实施例的数据处理的方法。

通过本发明，获取目标应用的逻辑业务层的待处理数据，并将待处理数据发送至数据访问层；在配置有目标插件的数据访问层中，基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果，其中，目标插件为基于Raisl引擎生成的且包含目标应用与其关联应用的公用数据访问层数据的插件；基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。也就是说，本发明将目标应用和其关联应用在数据访问层的公用数据访问层数据，通过目标插件进行实现，并且预先在数据访问层配置上述目标插件，进而在配置有上述目标插件的数据访问层中对待处理数据进行数据访问，而不用在目标应用和其关联应用中各自专门设置数据访问层的逻辑代码，避免了代码重复、数据臃肿，从而解决了应用的数据处理效率低的技术问题，进而达到了提高应用的数据处理效率的技术效果。

附图说明

构成本申请的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明实施例的一种数据处理的方法的移动终端的硬件结构框图；

图2是根据本发明实施例的一种数据处理的方法的流程图；

图3是根据本发明实施例的一种基于Rails的应用的目录结构的示意图；

图4是根据本发明实施例的一种Ruby On Rails应用项目复用数据访问层的应用架构的示意图；以及

图5是根据本发明实施例的一种数据处理的装置的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本发明实施例的一种数据处理的方法的移动终端的硬件结构框图。如图1所示，移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，可选地，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的一种数据处理的方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输设备106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备106可以为射频(RadioFrequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

在本实施例中提供了一种运行于上述移动终端的一种数据处理的方法，图2是根据本发明实施例的一种数据处理的方法的流程图。如图2所示，该方法可以包括如下步骤：

步骤S202，获取目标应用的逻辑业务层的待处理数据，并将待处理数据发送至数据访问层。

在本发明上述步骤S202提供的技术方案中，目标应用可以为WEB应用，可以具有不同类型，以满足用户在不同场景的操作需求，比如，目标应用可以为后台应用、PC端应用、移动端应用等。可选地，该实施例的目标应用为应用项目，该应用项目可以包括商家管理后台应用项目、PC端用户购物项目、移动端用户购物项目等，可以用于实现相应的业务功能，比如，用于实现用户注册、用户登录等。其中，商家管理后台应用项目、PC端用户购物项目、移动端用户购物项目之间互为关联应用，可以是在内容上相关联，将其统称为电商系统。

可选地，该实施例的上述目标应用可以为基于Rails架构的应用，也即，Rails应用，其中，Rails为基于MVC架构的基础框架。

可选地，该实施例的上述目标应用为基于Ruby On Rails框架的Rails应用，其中，Ruby On Rails框架为一个基于Ruby语言的Web开发框架，Ruby语言一种简单快捷面向对象编程而创的脚本语言。

在该实施例中，目标应用可以理解为引擎，该引擎为一个宿主(比如，Web应用)，可以是提供函数功能的中间件或插件，也即，其本身就可以作为一个插件为其它应用提供功能，而自己又可以嵌套很多其它的引擎。

在该实施例中，目标应用包括业务逻辑层和数据访问层，其中，业务逻辑层中具有需要在数据访问层进行处理的待处理数据。在获取到逻辑业务层的待处理数据之后，可以将待处理数据发送至数据访问层。

步骤S204，在配置有目标插件的数据访问层中，基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果。

在本发明上述步骤S204提供的技术方案中，目标插件为基于Raisl引擎生成的且包含目标应用与其关联应用的公用数据访问层数据的插件。

需要说明的是，在本发明实施例中，由于数据访问层中包含了目标插件，而目标插件中包含公用数据访问层数据，因此，目标应用及其关联应用都可以访问该数据访问层，即数据访问层为目标应用及其关联应用公用的数据访问层，目标应用及其关联应用均不需要再单独设置数据访问层，从而可以大大减少代码量，降低应用开发的复杂度。

该实施例可以预先向数据访问层配置目标插件，该目标插件包含了目标应用与其相关联应用的公用数据访问层数据，该公用数据访问层数据用于实现目标应用与其相关联应用在各自数据访问层所需要实现的相同数据访问处理的逻辑，使得目标插件可复用，也即，目标应用与其相关联应用在数据访问层上共用同一套用于对待处理数据进行数据访问处理的逻辑，该逻辑从业务角度来看，可以为需要在目标应用与其关联应用中均需实现的业务逻辑，比如，为数据库连接和对待处理数据进行一系列的增、删、改、查的逻辑，还可以包括注册用户、密码验证、修改密码等逻辑等。

可选地，该实施例的目标插件可以为Raisl引擎，可以利用RubyGems(Gems)可对Ruby组件进行打包并管理的特性，将需要应用在不同的目标应用中的数据访问层数据做成上述目标插件。其中，RubyGems是一个用于对Ruby组件进行打包并管理的工具。

在将待处理数据发送至数据访问层之后，在配置有上述目标插件的数据访问层中，基于上述目标插件对待处理数据进行数据访问处理，从而得到目标应用的数据访问处理结果，并输出该数据访问处理结果。

步骤S206，基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。

在本发明上述步骤S206提供的技术方案中，目标应用具有对应的数据库，该数据库用于与数据访问层进行数据交互，比如，在数据库中进行数据的写操作、在数据库中进行数据的读操作。在基于上述目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果之后，可以将数据访问处理结果传输至目标应用对应的数据库中，与数据库进行数据交互，以完成对业务逻辑层中的待处理数据进行处理的全部过程。

在相关技术中，目标应用与其关联应用都是包含各自独立的一套数据访问层来实现相同的逻辑，从而导致存在很多的代码、逻辑以及文件的重用；另外，将目标应用与其关联应用混合成一个整体，会使得各种不相关的逻辑混合于一处，从而导致应用日渐臃肿，难以扩展的问题。而在该实施例中，由于数据访问层中包含了目标插件，而目标插件中包含公用数据访问层数据，这样目标应用及其关联应用都可以访问该数据访问层，而均不需要再单独设置数据访问层，从而可以大大减少代码量，降低应用开发的复杂度。

通过本申请上述步骤S202至步骤S206中，获取目标应用的逻辑业务层的待处理数据，并将待处理数据发送至数据访问层；在配置有目标插件的数据访问层中，基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果，其中，目标插件为基于Raisl引擎生成的且包含目标应用与其关联应用的公用数据访问层数据的插件；基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。也就是说，本发明将目标应用和其关联应用在数据访问层的公用数据访问层数据，通过目标插件进行实现，并且预先在数据访问层配置目标插件，进而在配置有目标插件的数据访问层中对待处理数据进行数据访问，而不用在目标应用和其关联应用中各自专门设置数据访问层的逻辑代码，避免了代码重复、数据臃肿，从而解决了应用的数据处理效率低的技术问题，进而达到了提高应用的数据处理效率的技术效果。

下面对该实施例的上述方法进行进一步介绍。

作为一种可选的实施方式，目标插件中还包含Gem包。

在该实施例中，目标插件为基于Rails引擎生成的，在Rails引擎的根目录中的依赖描述文件(base.gemspec，功能类似于Gemfile)中，可以引入Gem包并设置其版本。其中，Gemfile为在Rails应用中被用于描述与Gem包之间的依赖关系的文件，Gem包是一种文件组织的包，可以理解为一种约定好的目录文件结构，是专门用来提供Ruby插件的，从而一个Gem即为一个Ruby插件。

在该实施例中，Rails引擎是利用Rails基础框架进行开发的，其中，Rails基础框架可以被看作是一个插件。该实施例可以在Gem包原有的约定好的目录文件结构基础上，又加入了Rails基础框架的一套目录文件结构，以对Gem包原有的约定好的目录文件结构进行扩展，可以使用Require方法并加上Rails基础数据框架中的目录文件结构的路径进行实现，进而将扩展后的目录文件结构确定为目标插件的目标结构目录。因而，上述在Rails引擎中引入Gem包可以得到Rails Gem，该Rails Gem指在Gem原有的约定好的目录文件结构基础上，引入Rails基础框架的目录文件结构，也即，向Ruby插件中引入Rails基础框架的目录文件结构，以得到目标插件。其中，引擎和Gem包之间的关系为：引擎>＝Gem包。

在该实施例中，目标插件可以包括目标应用与其关联应用在数据访问层的数据包，也即，公用数据访问层数据、公共访问层数据包、基础访问层数据包。该实施例可以一开始创建一个初始插件，该初始插件可以为还未填充有数据包的基础(base)Rails引擎，可以在初始插件中确定上述得到的目标结构目录，该目标结构目录可以为与目标应用相关的一些目录结构，比如，为与Rails应用相关的一些目录结构，可以是base/app/models等，向目标结构目录中填充公用数据访问层数据。

举例而言，数据库中有一个用户表，名为users，目标结构目录为base/app/models目录，可以在base/app/models目录中建立一个user.rb文件，里面有一个用户类，继承自ActiveRecord::Base类。ActiveRecord::Base类可以是目标插件用来封装数据库访问和操作的类，可以简单理解为里面包含数据库连接和提供了一系列增、删、改、查的函数，那么此时这个用户类就可以对用户表进行增、删、改、查，当然这个文件中还可以包含一系列业务方法，比如，注册用户、密码验证、修改密码等，这些就是要抽离出来的公用数据访问层数据，将其存储在base/app/models目录中，从而得到目标插件。

作为一种可选的实施方式，步骤S204，基于目标插件对待处理数据进行数据访问处理，包括：基于目标插件预先设置的自动加载属性，在目标插件中加载第一结构目录。

在该实施例中，目标插件可以预先设置有自动加载属性，可以在运行时，在目标插件中加载第一结构目录，该第一目录结构为自定义文件目录，可以与上述目标结构目录的名称可以预先约定为相同，比如，均为model。

可选地，该实施例在公用数据访问层数据中的lib/base/engine.rb文件中，利用目标插件预先设置的自动加载属性及其提供的钩子方法，设置自动加载目标应用的第一结构目录，比如，设置自动加载Rails App结构目录。

作为一种可选的示例，在该实施例中，启动目标应用，也即，启动管理器初始化，可以加载Rails基础数据框架中的各个组件，加载目标插件，进而加载第一结构目录。其中，在加载目标插件时，会利用Ruby插件的Require文件路径的方式自动加载目标插件，即会自动执行目标插件中的lib/base.rb文件，因而，该实施例可以利用这一步在启动管理器时注册目标插件中的自定义文件目录。具体步骤可以为：在目标插件的目录文件lib/base.rb中利用Require方法加上base/engine路径，使其在加载目标插件时，同时执行lib/base/engine.rb文件中的代码。该实施例还可以在lib/base/engine.rb文件中，定义一个Base::Engine类，继承自Rails::Engine类，该Rails::Engine类提供了一些钩子方法，比如，config.autoload_paths和config.eager_load_paths方法，这两个钩子方法是用来注册那些需要在目标应用启动时预加载的第一结构目录的。在使用时，是将第一结构目录以字符串数组的方式赋值给config.autoload_paths和config.eager_load_paths即可，如config.autoload_paths+＝["../../app/models"]，此时即注册完毕，进而自动加载上面已注册的第一结构目录。

作为一种可选的实施方式，步骤S204，基于目标插件对待处理数据进行数据访问处理之前，包括：判断当前的处理环境是否为线上环境；若当前的处理环境是线下环境，则基于目标应用中存储的本地路径获取目标插件；若当前的处理环境是线上环境，则基于目标应用中存储的远程地址获取目标插件。

在该实施例中，在基于目标插件对待处理数据进行数据访问处理之前，可以利用RubyGems的分组管理以及可按路径加载的特性，在目标应用的Gemfile文件中引入目标插件，可以先判断当前的数据处理的环境是否为线上环境。如果判断出当前的数据处理的环境为线下环境，则确定目标应用中存储的本地路径(相对路径)，通过该本地路径来获取目标插件，其中，在基于目标应用中存储的本地路径获取目标插件时，可以用命令加载，可以通过具体的环境来确定需要加载的目标插件。

如果判断出当前的数据处理的环境为线下环境，则确定目标应用中存储的远程地址，通过远程地址获取目标插件，其中，远程地址可以为网络资源定位符(UniformResourceLocation，简称为URL)。

作为一种可选的实施方式，本地路径存储于目标应用的development组中，远程地址存储于目标应用的production组中。

在该实施例中，若当前的处理环境是线下环境，本地路径存储于目标应用的开发(development)组中，可以从development组中确定本地路径，进而基于本地路径获取目标插件。可选地，在本地调试开发一个环境，可以边开发，边看调试结果，从而在开发development组中使用本地路径加载目标插件，可以方便在开发环境中进行代码调试。

在该实施例中，若当前的处理环境是线上环境，远程地址存储于目标应用的生产(production)组中，可以从production组中确定远程地址，进而基于远程地址获取目标插件，使用目标插件的URL(比如，git地址)加载，从而方便进行线上环境的版本控制。

作为一种可选的实施方式，步骤S204，基于目标插件对待处理数据进行数据访问处理，包括：加载目标应用对应的补丁文件和目标插件，补丁文件包含目标应用与其关联应用相差异的数据；基于目标插件和补丁文件对待处理数据进行数据访问处理。

在该实施例中，目标应用具有目标功能，该目标功能与目标应用的关联应用的功能不同，也即，差异功能、非公用部分的功能，比如，目标功能为用户注册功能，关联应用的功能为用户登录功能，可以通过补丁文件对目标插件所实现的数据访问处理的逻辑进行进一步补充，其中，补丁文件包含了目标应用与其关联应用相差异的数据，该相差异的数据用于实现上述目标功能。可选地，该实施例的补丁文件中的数据可以使用Ruby的动态打开类来进行实现，以便对目标应用与其关联应用相差异的数据进行管理。可选地，该实施例的补丁文件中的数据与目标插件包含的公用数据访问层数据属于同一类，比如，属于同一用户类，该实施例可以将补丁文件存储至目标应用的一个目录下，该目录可以为app/decorators文件夹，可以称为装饰器层，从而达到用于放置补丁文件的目的。

该实施例基于目标插件和补丁文件对待处理数据进行数据访问处理，从而共同来实现目标应用在数据访问层的完整数据处理逻辑。

举例而言，补丁文件中的数据与目标插件中的公用数据访问层数据属于同一用户类，目标应用A只需要用户注册功能，关联应用B只需要用户登录功能，那么就可以认为用户注册功能和用户登录功能不是公用的功能，而是目标应用A和关联应用B分别特有的功能，用户注册功能的代码和用户登录功能的代码就是用于区别于公用数据访问层数据的差异数据，此差异数据理应由目标应用A和关联应用B各自进行维护，却又同属于用户类中的逻辑，但是用户类中的公用数据访问层数据已经被抽离到了公用的数据访问层中，那么用户注册功能的代码和用户登录功能的代码可以分别放置在目标应用A和关联应用B中的装饰器层，具体的实现方式是在目标应用A和关联应用B的各自的项目目录中，创建app/decorators文件夹，可以在此文件夹中创建一个名为user_decorator.rb的补丁代码文件，里面则各自存放目标应用A和关联应用B的关于用户类在本项目中特有功能的逻辑代码。

该实施例可以利用Ruby的class_eval方法方便地动态打开上述用户类，往用户类中补充特有功能的逻辑代码(差异数据)，并且目标应用A和关联应用B的用户类代码也不会出现冲突。比如，目标应用A中的user_decorator.rb文件在实现上，类似于User.class_eval{…这里是用户注册功能的代码…}，关联应用B中的user_decorator.rb文件在实现上，类似于User.class_eval{…这里是用户登录功能的代码…}。

通过上述方法，数据访问层中包含了目标插件，而目标插件中包含公用数据访问层数据，从而该实施例的公用数据访问层数据已抽离，这样目标应用及其关联应用都可以访问该数据访问层，而均不需要再单独设置数据访问层，从而可以大大减少代码量，降低应用开发的复杂度，而相差异的数据则可以自行管理，同一个类中的代码也可以分开存放，从而提高了数据处理效率。

作为一种可选的实施方式，加载目标应用对应的补丁文件和目标插件，包括：根据目标应用的配置文件自动加载目标应用对应的补丁文件和目标插件。

在该实施例中，在实现加载目标应用对应的补丁文件和目标插件时，可以确定目标应用的配置文件，比如，该配置文件为config/application.rb文件，可以在config/application.rb文件中设置用于自动加载的信息，进而根据该自动加载的信息来自动加载目标应用对应的补丁文件和目标插件，以基于目标插件和补丁文件对待处理数据进行数据访问处理，进而基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。

作为一种可选的实施方式，步骤S206，基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互，包括：将目标应用的数据访问处理结果写入数据库中；或者，通过目标应用的数据访问处理结果从数据库中读取对应的目标数据。

在该实施例中，在基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果之后，基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互，可以是将目标应用的数据访问处理结果直接写入数据库中，该数据库可以保存该数据访问处理结果，或者后续通过其它客户端或服务器对其进行调用以实现与目标应用的业务相关的处理。可选地，该实施例还可以通过目标应用的数据访问处理结果从数据库中读取对应的目标数据，将读取的目标数据作为处理的对象，以实现目标应用的相应功能。

在相关技术中，实现相同数据处理逻辑的一套公用数据访问层数据，被分散应用于目标应用与其关联应用中。而该实施例对公用数据访问层数据进行抽离，以便对其集中管理，可以利用RubyGems可对Ruby组件进行打包并管理的特性，可将数据访问层做成Rails引擎；可以利用Rails引擎作为超级引擎的特性，将公用数据访问层数据作为目标插件来使用，由于数据访问层中包含了目标插件，而目标插件中包含公用数据访问层数据，这样目标应用及其关联应用都可以访问该数据访问层，而均不需要再单独设置数据访问层，从而可以大大减少代码量，降低应用开发的复杂度；并且利用Ruby的可动态打开类特性，来对不同目标应用中的相差异的数据进行管理，从而解决了应用的数据处理效率低的技术问题，进而达到了提高应用的数据处理效率的技术效果。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

下面结合优选的实施方式对本发明的上述技术方案进行举例说明。

互联网的入口通常会包括多个，比如，包括PC端、移动端等。通常一个Web应用为了满足用户在不同场景的操作需求，会针对不同的入口开发不同的应用项目，比如，商家管理后台项目、PC端用户购物项目、触屏版用户购物项目等应用项目。

但是，但是对于后端项目来说，在数据访问层上基本都是相同的数据逻辑，只是应用层的用户接口不一样而已。Ruby On Rails(Rails)项目尤其如此，Rails的开发效率极高，可以被用来开发单体Web项目。

图3是根据本发明实施例的一种基于Rails的应用的目录结构的示意图。如图3所示，Rails是基于MVC架构，其应用的目录结构一般如下：

App-name/

--app/

----controllers/

----models/

----views

--config/

----application.rb

--lib/

Gemfile

…

model即数据访问层，WAP端应用可以为移动端网页，比如，为手机浏览器。PC端应用和WAP端应用在数据访问层上基本都是相同的逻辑，只是应用层的用户接口不一样而已。

当出现多个应用需要共用同一套数据的时候，一般的解决方法为：每个应用都包含各自的一套数据访问层和业务逻辑层。但是，该方法带来的问题是：具有很多的代码、逻辑及导致文件的重用；还可以将多个应用混合成一个项目。但是，该方法带来的问题是：各种不相关的逻辑混合于一处，从而导致项目日渐臃肿，难以扩展。

以上的方案都加剧了应用开发的复杂性，也加大了后续维护流程上的人力及时间成本。

该实施例即为如何构建可复用的数据访问层的方法，以降低开发成本，有效的进行项目代码的管理，从而方便日后项目的维护及迭代。

在相关技术中，导致对应用的数据处理效率低的问题的根本原因在于，同样的一套公用数据访问层数据，会被分散应用于不同的应用中。因而，该实施例考虑对需要应用在不同的应用中的公用数据访问层数据进行抽离，以便对其进行集中管理。

该实施例可以利用RubyGems(Gems)可对Ruby组件进行打包并管理的特性，将需要应用在不同的应用中的公用数据访问层数据做成Rails引擎。其中，RubyGems的功能类似于linux下的apt-get。

该实施例可以利用Rails应用作为超级引擎的特性，将公用数据访问层数据生成Rails应用的目标插件来使用。

利用Ruby的可动态打开类特性，来对不同应用项目中的数据访问层涉及的差异代码进行管理。

下面对该实施例的针对数据访问层，抽离公用数据访问层数据的方法进行介绍。

在该实施例中，创建一个Rails引擎，该Rails引擎中会包含与Rails应用相关的一些目录结构，比如app/models等，将该Rails引擎命名为base，也即，base引擎，此即为公用数据访问层数据的名称。其中，引擎可以理解为一个宿主(比如，Web应用)提供函数功能的中间件或插件，一个Rails应用可以被看作是一个功能强大的引擎，其本身就可以作为一个插件为其它应用提供功能，而它自身也可以嵌套很多的引擎。

在Rails引擎的根目录中的依赖描述文件(base.gemspec，功能类似于Gemfile)中，可以引入目录文件结构Rails Gem并设置其版本。其中，Rails Gem中的Gem包是一种文件组织的包，可以理解为一种约定好的目录文件结构。

在该实施例中，Rails应用项目是用Rails基础框架进行开发的，Rails基础框架可以被看作是一个插件，只不过该实施例在Gem包原有的约定好的目录文件结构基础上，又加入了Rails基础框架的一套目录文件结构，做了扩展。所以上述的引入RailsGem的意思是在Gem包原有的目录文件结构基础上，引入Rails基础框架的目录文件结构，也即，向Ruby插件中引入Rails基础框架的目录文件结构，将Rails引擎对应的数据存储至得到的目录文件结构中。

在该实施例中，在Rails引擎中的子目录lib/base/engine.rb文件中，可以利用Rails引擎的应用初始化加载机制及其提供的钩子方法，设置自动加载Rails应用的结构目录。

下面对该实例的启动管理器初始化(即启动)Rails应用项目的过程进行如下介绍：

第一步，加载Rails基础框架的各个组件；第二步，加载插件；第三步，加载自定义文件目录。

其中，在第二步，加载插件时，会利用Ruby插件中的Require文件路径的方式自动加载Rails引擎，即会自动执行Rails引擎中的lib/base.rb文件，所以该实施例可以利用这一步在启动管理器中注册Rails引擎中的自定义目录。具体步骤可以为：在Rails引擎目录文件lib/base.rb中利用Require方法加上‘ase/engine’路径，使其在加载Rails引擎时，同时执行Rails引擎中的子目录lib/base/engine.rb文件中的代码。

可选地，该实施例在Rails引擎中的子目录lib/base/engine.rb文件中，可以定义一个Base::Engine类，继承自Rails::Engine类，该Rails::Engine类提供了一些钩子方法，比如，config.autoload_paths方法和config.eager_load_paths方法，这两个钩子方法是用于注册那些需要在项目应用启动时预加载的自定义目录的。在使用时，是将自定义目录以字符串数组的方式赋值给config.autoload_paths和config.eager_load_paths即可，比如，config.autoload_paths+＝["../../app/models"]，此时即注册完毕。

在第三步的加载自定义文件目录时，就会自动加载上面已注册的目录结构。

在该实施例中，公用数据访问层数据即为需要抽离出来的代码，置于Rails引擎中的base/app/models目录中，得到目标插件。至此，公用数据访问层数据抽离完毕，且其在应用初始化时也可正常加载。

举例而言，数据库中有一个用户表，名为users，那么就可以在Rails引擎中的base/app/models目录中建立一个user.rb文件，里面有一个用户类，继承自ActiveRecord::Base类。ActiveRecord::Base类是Rails引擎用来封装数据库访问和操作的类，可以简单理解为里面包含数据库连接以及提供了一系列增、删、改、查的函数。那么此时这个用户类就可以对用户表进行增、删、改、查了，当然这个文件中还会包含一系列的业务方法，比如，注册用户、密码验证、修改密码等，这些就是该实施例需要抽离出来的公用数据访问层代码，因为从业务角度来看，这些操作一般都会在多个应用项目里同时用到，也即，一个文件的代码可以在多个Rails应用中共用。

下面对该实施例的在具体的应用项目中该如何引入目标插件(Rails引擎)的方法进行介绍。

在该实施例中，可以利用RubyGems的分组管理以及可按路径加载的特性，在应用项目的Gemfile文件中引入Rails引擎。可选地，本地启动一个应用项目，在开发组(development)组中使用相对路径加载，方便开发环境进行代码调试；在生产(production)组生成中使用远程地址(如：git地址)加载Rails引擎，方便进行线上环境的版本控制。

在该实施例中，可以在项目应用中创建app/decorators文件夹，并在项目应用中的config/application.rb文件中设置为自动加载Rails引擎。

可选地，该实施例通过app/decorators文件夹用于放置数据访问层的补丁代码，补丁代码可以使用Ruby的动态打开类来实现，以便对不同应用项目中的数据访问层的差异代码进行管理。

举例而言，上面提到过的用户类，A项目应用只需要用户注册功能，B项目应用只需要用户登录功能，那么就可以认为【用户注册】和【用户登录】不是公用的功能，而是A项目应用、B项目应用特有的功能，这部分代码就是用于区别于公用数据访问层代码的差异代码。此差异代码理应由A项目应用、B项目应用各自维护。该实施例可以约定好了一个地方，那就是在A项目应用、B项目应用中引入“装饰器层”，具体的实现方式是在A项目应用、B项目应用的各自项目目录中创建app/decorators文件夹。对于上面的例子，该实施例可以在此文件夹中创建一个名为user_decorator.rb的补丁代码文件，里面则各自存放A项目应用和B项目应用关于用户类在本项目中特有功能的逻辑代码。

该实施例可以利用Ruby的class_eval方法就可以很方便地动态打开用户类，往用户类中补充逻辑代码了，并且A项目应用、B项目应用的用户类代码也不会出现冲突。

通过上述方法，公用数据访问层数据已抽离，非公用部分则各个项目应用可以自行管理，同一个类中的代码分开在对应的项目应用中存放。

图4是根据本发明实施例的一种Ruby On Rails应用项目复用数据访问层的应用架构的示意图。如图4所示，项目应用包括PC端应用和WAP端应用，其中，PC端应用包括自己的一套业务逻辑层(Controller)，WAP端应用包括自己的一套业务逻辑层(Controller)，可以将公用数据访问层数据放置于一个单独的项目目录Model中，供数据库使用，从而有效地避免了代码的复制，将需要维护的代码量由n减少到1，极大地方便了不同开发人员的开发及协作、维护，并且也符合Rails的不要重复自己的原则，从而提高了应用的数据处理效率，解决了应用的数据处理效率低的技术问题。

需要说明的是，在本发明实施例中，由于数据访问层中包含了目标插件，而目标插件中包含公用数据访问层数据，因此，目标应用及其关联应用都可以访问该数据访问层，即数据访问层为目标应用及其关联应用公用的数据访问层，目标应用及其关联应用均不需要再单独设置数据访问层，从而可以大大减少代码量，降低应用开发的复杂度。

本发明实施例还提供了一种数据处理的装置。需要说明的是，该实施例的数据处理的装置可以用于执行本发明实施例图2所示的数据处理的方法。

图5是根据本发明实施例的一种数据处理的装置的示意图。如图5所示，该数据处理的装置50包括：获取单元51、处理单元52和交互单元53。

获取单元51，用于获取目标应用的逻辑业务层的待处理数据，并将待处理数据发送至数据访问层。

处理单元52，用于在配置有目标插件的数据访问层中，基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果，其中，目标插件为基于Raisl引擎生成的且包含目标应用与其关联应用的公用数据访问层数据的插件。

交互单元53，用于基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。

可选地，目标插件中还包含Gem包。

可选地，处理单元52包括：第一加载模块，用于基于目标插件预先设置的自动加载属性，在目标插件中加载第一结构目录。

可选地，该装置还包括：判断单元，用于基于目标插件对待处理数据进行数据访问处理之前，判断当前的处理环境是否为线上环境；第一获取单元，用于当前的处理环境是线下环境，则基于目标应用中存储的本地路径获取目标插件；第二获取单元，用于在当前的处理环境是线上环境，则基于目标应用中存储的远程地址获取目标插件。

可选地，本地路径存储于目标应用的development组中，远程地址存储于目标应用的production组中。

可选地，处理单元52包括：第二加载模块，用于加载目标应用对应的补丁文件和目标插件，补丁文件包含目标应用与其关联应用相差异的数据；处理模块，用于基于目标插件和补丁文件对待处理数据进行数据访问处理。

可选地，第二加载模块包括：记载子模块，用于根据目标应用的配置文件自动加载目标应用对应的补丁文件和目标插件。

可选地，交互单元53包括：写入模块，用于将目标应用的数据访问处理结果写入数据库中；或者，读取模块，用于通过目标应用的数据访问处理结果从数据库中读取对应的目标数据。

可选地，目标应用为Rails应用，目标插件为Rails引擎。

在该实施例中，通过获取单元51获取目标应用的逻辑业务层的待处理数据，并将待处理数据发送至数据访问层；通过处理单元52在配置有目标插件的数据访问层中，基于目标插件对待处理数据进行数据访问处理，得到目标应用的数据访问处理结果，其中，目标插件为基于Raisl引擎生成的且包含目标应用与其关联应用的公用数据访问层数据的插件；通过交互单元53基于目标应用的数据访问处理结果与目标应用对应的数据库进行数据交互。也就是说，本发明将目标应用和其关联应用在数据访问层的公用数据访问层数据，通过目标插件进行实现，并且预先在数据访问层配置上述目标插件，进而在配置有上述目标插件的数据访问层中对待处理数据进行数据访问，而不用在目标应用和其关联应用中各自专门设置数据访问层的逻辑代码，避免了代码重复、数据臃肿，从而解决了应用的数据处理效率低的技术问题，进而达到了提高应用的数据处理效率的技术效果。

本发明的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种数据处理的方法，其特征在于，包括：

获取目标应用的逻辑业务层的待处理数据，并将所述待处理数据发送至数据访问层；

在配置有目标插件的数据访问层中，基于所述目标插件对所述待处理数据进行数据访问处理，得到所述目标应用的数据访问处理结果，其中，所述目标插件为基于Rails引擎生成的且包含所述目标应用与其关联应用的公用数据访问层数据的插件；

基于所述目标应用的数据访问处理结果与所述目标应用对应的数据库进行数据交互；

其中，基于所述目标插件对所述待处理数据进行数据访问处理，包括：加载所述目标应用对应的补丁文件和目标插件，所述补丁文件包含所述目标应用与其关联应用相差异的数据；基于所述目标插件和所述补丁文件对所述待处理数据进行数据访问处理。

2.根据权利要求1所述的方法，其特征在于，所述目标插件中还包含Gem包。

3.根据权利要求1所述的方法，其特征在于，所述基于所述目标插件对所述待处理数据进行数据访问处理，包括：

基于所述目标插件预先设置的自动加载属性，在所述目标插件中加载第一结构目录。

4.根据权利要求1所述的方法，其特征在于，所述基于所述目标插件对所述待处理数据进行数据访问处理之前，包括：

判断当前的处理环境是否为线上环境；

若当前的处理环境是线下环境，则基于所述目标应用中存储的本地路径获取所述目标插件；

若当前的处理环境是线上环境，则基于所述目标应用中存储的远程地址获取所述目标插件。

5.根据权利要求4所述的方法，其特征在于，所述本地路径存储于所述目标应用的development组中，所述远程地址存储于所述目标应用的production组中。

6.根据权利要求1所述的方法，其特征在于，所述加载所述目标应用对应的补丁文件和目标插件，包括：

根据所述目标应用的配置文件自动加载所述目标应用对应的补丁文件和目标插件。

7.根据权利要求1至6中任意一项所述的方法，其特征在于，基于所述目标应用的数据访问处理结果与所述目标应用对应的数据库进行数据交互，包括：

将所述目标应用的数据访问处理结果写入所述数据库中；或者，

通过所述目标应用的数据访问处理结果从所述数据库中读取对应的目标数据。

8.根据权利要求1至6中任意一项所述的方法，其特征在于，所述目标应用为Rails应用，所述目标插件为Rails引擎。

9.一种数据处理的装置，其特征在于，包括：

获取单元，用于获取目标应用的逻辑业务层的待处理数据，并将所述待处理数据发送至数据访问层；

处理单元，用于在配置有目标插件的数据访问层中，基于所述目标插件对所述待处理数据进行数据访问处理，得到所述目标应用的数据访问处理结果，其中，所述目标插件为基于Rails引擎生成的且包含所述目标应用与其关联应用的公用数据访问层数据的插件；

交互单元，用于基于所述目标应用的数据访问处理结果与所述目标应用对应的数据库进行数据交互；

其中，所述处理单元通过以下步骤基于所述目标插件对所述待处理数据进行数据访问处理，包括：加载所述目标应用对应的补丁文件和目标插件，所述补丁文件包含所述目标应用与其关联应用相差异的数据；基于所述目标插件和所述补丁文件对所述待处理数据进行数据访问处理。

10.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至8任一项中所述的方法。

11.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至8任一项中所述的方法。

Images