吳勤 莊紅 鐵治欣 劉晶晶

摘要：業(yè)務(wù)邏輯層（BLL）與數(shù)據(jù)訪問層（DAL）是MVC的核心層，BLL與DAL的實現(xiàn)，使Web應(yīng)用系統(tǒng)具有更好的低耦合度，高模塊化程度，易維護，易擴展。通過對傳統(tǒng)的BLL與DAL的模型結(jié)構(gòu)的進一步研究，分析出傳統(tǒng)BLL與DAL存在重復(fù)率高，利用率低的缺陷。因此提出在Web應(yīng)用中基于JPA規(guī)范和泛型程序設(shè)計，采用Spring Data JPA的BLL與DAL層的Nosql模型。通過該模型應(yīng)用和模型評估，發(fā)現(xiàn)該模型與傳統(tǒng)的模型結(jié)構(gòu)相比，代碼量少，利用率高，提高了Web應(yīng)用軟件的開發(fā)效率。

關(guān)鍵詞：業(yè)務(wù)邏輯層；數(shù)據(jù)訪問層；通用泛型；JPA規(guī)范；SpnngDataJPA；Nosql模型中圖分類號：TP311.5文獻標(biāo)識碼：ADOI：10.3969/j.issn.1003-6970.2017.08.008

本文著錄格式：吳勤，莊紅，鐵治欣，等.業(yè)務(wù)邏輯層與數(shù)據(jù)訪問層的Nosql模型研究[J].軟件，2017，38（8）：4349

引言

BLL與DAL是MVC模式的重要兩個分層，將傳統(tǒng)模式下業(yè)務(wù)邏輯和數(shù)據(jù)操作有效的劃分開，有效的解決了兩者混雜導(dǎo)致的系統(tǒng)難于維護和拓展的弊端，大大提高了開發(fā)效率和系統(tǒng)性能。泛型是JDK1.5的新特性，允許編寫可作用于任意類型的類，直到聲明了類的實例，才指定特定的類型。使用泛型的主要優(yōu)點是能夠使我們在編譯時而不是運行時檢測出錯誤。JPA是Java官方提出的、隨Java EE5規(guī)范一同發(fā)布的，在此之前，已經(jīng)存在很多ORM框架了，他們都有不同的實現(xiàn)，這也是JAP出現(xiàn)的必然條件，它規(guī)范ORM框架，是ORM框架有統(tǒng)一的接口和用法。文獻[5-6]對數(shù)據(jù)持久層提出使用Spring Data和JPA構(gòu)建持久層這一方法，闡述這種方法讓數(shù)據(jù)訪問層開發(fā)量變少的原因，并且分析它訪問數(shù)據(jù)庫的過程。將這種方法應(yīng)用到Java EE系統(tǒng)中，與傳統(tǒng)的構(gòu)建持久層方法相比，這種方法使開發(fā)人員從繁瑣的數(shù)據(jù)訪問層中解放出來，不需要寫大量的代碼，只需要少量的代碼就可以實現(xiàn)對數(shù)據(jù)庫的訪問，但是業(yè)務(wù)邏輯層還需要寫大量的代碼來完成項目的開發(fā)[、15]。文獻[17-19]講述了一種動態(tài)生成sql語句的方法?；诖?，提出一種在Web應(yīng)用中基于Spring Data JPA、通用泛型的BLL與DAL層的Nosql模型，從而減少大部業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層的代碼。

1 BLL與DAL層泛型引入

1.1 傳統(tǒng)BLL與DAL層設(shè)計

業(yè)務(wù)邏輯層（BLL）是應(yīng)用系統(tǒng)中的核心，負責(zé)處理系統(tǒng)具體的業(yè)務(wù)邏輯。在該實現(xiàn)框架中，業(yè)務(wù)邏輯層由純業(yè)務(wù)邏輯類和AOP處理程序組成。純業(yè)務(wù)邏輯類負責(zé)完成與具體業(yè)務(wù)密切相關(guān)的業(yè)務(wù)邏輯處理，AOP處理程序負責(zé)權(quán)限管理、事務(wù)管理、日志管理等非純業(yè)務(wù)的邏輯處理。每個業(yè)務(wù)模塊擁有獨立的業(yè)務(wù)處理邏輯，每個業(yè)務(wù)需要一一的針對單一的對象進行業(yè)務(wù)處理操作。因而會造成重復(fù)的代碼，代碼利用率不高，降低了開發(fā)效率。

數(shù)據(jù)訪問層主要是封裝業(yè)務(wù)處理邏輯與數(shù)據(jù)存儲層之間的交互過程，向業(yè)務(wù)邏輯層提供數(shù)據(jù)服務(wù)。在具體的應(yīng)用開發(fā)中，數(shù)據(jù)訪問層有多種不同的實現(xiàn)方式。業(yè)務(wù)模塊根據(jù)業(yè)務(wù)邏輯，調(diào)用對應(yīng)DAO接口，實現(xiàn)接口，最后實現(xiàn)ORM。傳統(tǒng)業(yè)務(wù)邏輯層與數(shù)據(jù)訪問層的業(yè)務(wù)過程如圖1所示：

在項目開發(fā)過程中，傳統(tǒng)的BLL與DAL層設(shè)計，代碼重復(fù)率高，利用率低，從而開發(fā)效率低。1.2Java程序中泛型設(shè)計Java5.0的新特性是引入了泛型，泛型允許編寫可作用于任意類型的類，但是直到聲明了類的實例，才指定特定的類型。因為此類型不是作為類定義的一部分而指定的，所以該類一般對任意指定類型起作用。這個能力使我們可以定義帶泛型類型的類或是方法，隨后編譯器會用具體的類型來替換它。因此泛型可以使我們在編譯時而不是在運行時檢測出錯誤。泛型是類型的安全性增加。

1.3 將Java泛型引入BLL與DAL層

圖一中是傳統(tǒng)的BLL與DAL層，它可以完成系統(tǒng)業(yè)務(wù)以及數(shù)據(jù)的訪問，但在開發(fā)中存在著一些不足。第一，BLL與DAL層的代碼重復(fù)率過高，開發(fā)效率低；此外，實現(xiàn)類的方法使代碼顯得比較繁瑣；第三，主鍵值以及實體類型需要指定，頻繁的轉(zhuǎn)換返回結(jié)果值的類型。通過引用泛型，從而解決上述一系列的問題，而且泛型可以使代碼在編譯時，而不是在運行時檢測出錯誤。

與傳統(tǒng)的BLL與DAL層設(shè)計相比，構(gòu)建泛型是類型安全、代碼精簡的設(shè)計方式，在業(yè)務(wù)龐大項目中，代碼明顯的減少，對于項目成本，時間，工作量帶來了有利的條件。通過封裝BLL與DAL層基類泛型，從而達到優(yōu)化BLL與DAL層設(shè)計目的。

2 基于JPA規(guī)范的SpringDataJPA的運用

2.1 JPA規(guī)范介紹

JPA（Java Persistence API）是JavaEE平臺標(biāo)準(zhǔn)的規(guī)范，將得到服務(wù)器的支持。在吸收現(xiàn)有框架的基礎(chǔ)上，是一個易于使用、伸縮性強的規(guī)范。JPA規(guī)范本質(zhì)上是一種ORM規(guī)范，它不是ORM框架，因為JPA并未提供ORM實現(xiàn)，它只是制訂了一些規(guī)范，提供了一些編程的API接口，但具體實現(xiàn)則由服務(wù)廠商來提供實現(xiàn)，例如，JBoss應(yīng)用服務(wù)器底層就以Hibernate作為JPA的實現(xiàn)。即JPA規(guī)范中提供的只是一些接口，接口不能直接拿來使用。雖然應(yīng)用程序可以面向接口編程，但JPA底層一定需要某種JPA實現(xiàn)，否則JPA依然無法使用。因此開發(fā)者面向JPA規(guī)范的接口，但底層的JPA實現(xiàn)可以任意切換Hibernate、EBATIS、TopLink等。

2.2 Spring Data JPA與JPA規(guī)范的關(guān)系

Spring datajpa的目標(biāo)是簡化關(guān)于各種持久存儲數(shù)據(jù)訪問層而努力。ORM框架都實現(xiàn)了JPA規(guī)范，但是在不同ORM框架之間切換是需要編寫的代碼有一些差異，而通過使用Spring DataJpa能夠方便在不同的ORM框架中間進行切換而不要更改代碼。并且Spring DataJpa對Repository層封裝的很好，可以減少很多的麻煩。

Spring Data JPA與JPA規(guī)范的關(guān)系如圖2所示：

3 BLL與DAL層設(shè)計基于Spring Data

JPA、通用泛型的模型實現(xiàn)

在項目開發(fā)中，以Java泛型與Spring Data JPA

為基礎(chǔ)，在業(yè)務(wù)邏輯層與數(shù)據(jù)庫訪問層構(gòu)建Nosql模型。

3.1 相關(guān)配置

首先，配置JPA標(biāo)準(zhǔn)配置文件persistence.xml。然后，在Spring配置文件applicationContext.xml中增加JPA支持，即實體管理器工廠Entity Manager Factor，它是獲得實體管理器Entity Manager對象的入口?最后，在Spring配置文件中配置啟用掃描并自動創(chuàng)建代理的功能，Sprmg為聲明的接口創(chuàng)建代理對象。配置了后，Spring初始化容器時將會掃描base-package指定的包目錄及其子目錄，為繼承Repository或其子接口的接口創(chuàng)建代理對象，并將代理對象注冊為Spring Bean，業(yè)務(wù)層便可以通過Spring自動封裝的特性來直接使用該對象。

3.2 BLL層與DAL層的Nosql模型設(shè)計

3.2.1 模型中變量定義

定義1對象列操作{EQ，NOTEQ，LIKE，GT，LT，GTE，LTE，IN，NULL，NOTNULL}。

其中，EQ：等于；NOTEQ：不等于；LIKE：比較較相似的值；GT：大于

LT：小于；GTE：大于等于；LTE：小于等于；IN：

指定值在已指定一個值的列表

NULL：空；NOTNULL：不為空

3.2.2 模型思想

邏輯層建立一個公共的泛型業(yè)務(wù)邏輯處理模型，實體業(yè)務(wù)邏輯類繼承公共泛型模型，通過反射，獲得指定類的父類的泛型參數(shù)的實際類型，從而完成實際類型的業(yè)務(wù)邏輯操作。公共的泛型業(yè)務(wù)邏輯處理模型實現(xiàn)添加、修改、刪除、查詢。添加通過系統(tǒng)調(diào)用傳遞過來的封裝實體參數(shù)完成新增功能。修改根據(jù)系統(tǒng)傳遞過來修改過的實體進行保存。刪除根據(jù)系統(tǒng)調(diào)用傳遞過來的參數(shù)id或整個實體進行刪除。查詢通過系統(tǒng)調(diào)用傳遞過來的參數(shù)，參數(shù)為查詢條件操作key-value集合，以及排序操作集合。然后，根據(jù)條件操作進行動態(tài)的查詢條件拼接，或排序操作進行分頁排序，詳細說明參見算法1和算法2。最后，調(diào)用數(shù)據(jù)訪問層Spring Data JPA相應(yīng)基本操作接口，從而實現(xiàn)Nosql的操作。

算法1分頁排序算法

算法參數(shù)：頁碼，分頁數(shù)量，排序的對象集

//排序的對象集，為排序?qū)ο蟮募希判驅(qū)ο蟀▽傩院头较?/p>

返回值：Pageable型對象過程：

Begin

1、 Sortsort=null//倉1J建——個org.springframework.data.domain.Sort的sort排序?qū)ο?/p>

2、 If“排序的對象集”為空，排序根據(jù)數(shù)據(jù)庫id排序

3、 Else“排序的對象集”不為空且大小大于0

4、 獲取“排序的對象集”的第一個排序?qū)ο髮傩院头较?/p>

5、 If升序=排序的對象集升序方向

6、 sort=newSort（升序，屬性）

7、 elsesort=newSort（降序，屬性）

8、 for“排序的對象集”//從排序的對象集for第二個對象開發(fā)for循環(huán)直至結(jié)束

9、 獲取“排序的對象集”的下一個排序?qū)ο髮傩院头较?/p>

10、 If升序=排序的對象集升序方向sort.and（升序，屬性）

12、 elsesort.and（降序，屬性）

13、 返回一個new Page Request（頁碼-1，分頁數(shù)量，sort）即Page Request通過參數(shù)生成Pageable對象；

//Spring DataJpa提供了Page Request的具體實現(xiàn)，通過提供分頁以及排序信息即可。Pageable是Spring Data庫中定義的一個接口，該接口是分頁相關(guān)信息的一個抽象，通過該接口，可以得到和分頁相關(guān)所有信息（例如頁碼、分頁數(shù)量等），這樣，Jpa就能夠通過pageable參數(shù)來得到一個帶分頁信息的Sql語句。

End

算法2動態(tài)查詢條件拼接器算法

算法參數(shù)：查詢條件key-value集合，泛型類返回值：拼接好的條件組合

//key形如LIKE_topic，其中LIKE為操作，topic為操作字段，value為值。或者key形如為EQ_user.name，其中EQ為操作，user.name為操作字段，user連接的子表，name為子表的字段名

過程：

Begin

1、聲明包含屬性“對象列名稱”，“對象列值”，“對象列操作”，“加入的其他表對象標(biāo)志”的一個“條件對象”

2、 聲明一個Map型“條件對象型集合”

3、 Forkey-value集合

4、 獲取key與value值，如果value為空continue

繼續(xù)

5、 對value進行Java標(biāo)準(zhǔn)語言類型處理

6、 根據(jù)key分解出條件對象的屬性以及對應(yīng)的value，賦值“條件對象”屬性

7、 添加到Map型“條件對象型集合”

8、 ForMap型“條件對象型集合”

9、 獲取“條件對象”列名稱（形如：user.name或topic）拆分為“條件對象”列名稱數(shù)組

10、 If“條件對象”的“加入其他表對象標(biāo)志”不為空

11、 創(chuàng)建一個javax.persistence.criteria.Predicate類型的predicates對象集合

12、 If對象列名稱數(shù)組不為空，且大于1

13、 If“加入其他表對象標(biāo)志”為join

14、 定義了查詢的FROM子句中能夠出現(xiàn)的類型及其對象列名expression[3-4]//該句實現(xiàn)連表功會b，expression為javax.persistence.criteria.Path的一個對象

15、 Else定義了查詢的FROM句中能夠出現(xiàn)的類型及其對象列名expression

16、 switch（對象列操作）{caseEQ：predicates.add（builder.equal（expression，對象列值））；//builder為javax.persistence.criteria.CriteriaBuilder創(chuàng)建的一個對象

break；

caseNOTEQ：

predicates.add（buMer.notEqual（expression，對象列值））；

break；caseLIKE：

predicates.add（builder.like（expression，對象列值+n%））；

break；caseGT：

predicates.add（builder.greaterThan（expression，對象列值））；

break；caseLT：

predicates.add（builder.lessThan（expression，對象列值））；

break；caseGTE：

predicates.add（builder.greaterThanOrEqualTo（expression，對象列值））；

break；caseLTE：

predicates.add（builder.lessThanOrEqualTo（expression，對象列值））；

break；caseIN：

Inin=builder.in（expression）；

“對象列值”轉(zhuǎn)化為對象列值數(shù)組

For對象列值數(shù)組

in=in.value（值）；

predicates.add（in）；

break；

case

NULL：predicates.add（builder.isNull（expression））；

break；

caseNOTNULL：

predicates.add（builder.isNotNull（expression））；break；

}

//將所有條件用and聯(lián)合起來

17、 if（predicates.size（）>0）

18、 returnbuilder.and（predicates.toArray（newPredicate[predicates.size（）]））；

//返回一個拼接好的條件組合

End

3.2.3 Nosql模型說明

參考文獻[5-6]對Spring Data和JPA進行了一些研究，并闡述了Repository基本的用處，提供了Repository最基本的數(shù)據(jù)訪問功能，對下面的幾個方面做詳細的使用介紹：1、Cmd Repository繼承Repository實現(xiàn)了一組增加刪除修改查詢相關(guān)的方法。

2、Paging And Sorting Repository繼承Cmd Repository，

實現(xiàn)了一組分頁排序相關(guān)的方法。3、Jpa Repository繼承Paging And Sorting Repository，實現(xiàn)一組JPA規(guī)范相關(guān)的方法。上述為基本的功能，碎片化形式在項目開發(fā)中，沒有集成和優(yōu)化處理，因而降低了開發(fā)效率，下面提出了一種Nosql模型，它對基本數(shù)據(jù)訪問功能進行了優(yōu)化和多功能化研究與處理。下面是Nosql模型包含的主要的部分。

其中：search Params：查詢條件key-value集合；final Classclazz：是需要反射的類，該類必須繼承范型父類，通過反射，獲得指定類的父類的泛型參數(shù)的實際類型，從而減少代碼量；

build Page Request：采用算法1完成分頁排序算法；build Specification：采用算法2完成動態(tài)查詢條件拼接；

findAll（）、save（entity）、delete（id）、deleteAll（）page Number：頁碼page Size：分頁數(shù)量

Specification：org.springframework.data.jpa.domain.Specification的一個類對象

1、 實現(xiàn)多功能排序查詢

publicListgetList（Map

Sortsort，finalClassclazz）{

Specificationspec=buildSpecification（searchParams，clazz）；

returnthis.getDao（）.findAll（spec，sort）；

//多功能查找所有實體}

2、 實現(xiàn)多功能分頁查詢

publicPagegetList（Mapclazz）{PageRequestpageRequest=buildPageRequest（pageNumber，pageSize，sortType）；

Specificationspec=buildSpecification（searchParams，clazz）；

returnthis.getDao（）.findAll（spec？pageRequest）；

}

3、 實現(xiàn)列表查詢

publicListfindAll（）{

Iterableiter=this.getDao（）.findAll（）；

returnLists.newArrayList（iter）；}

4、實現(xiàn)排序列表查詢

publicListfindAll（Sortsort）{

Iterableiter=this.getDao（）.findAll（sort）；

returnLists.newArrayList（iter）；

}

5、 保存實體

publicvoidsave（Tentity）{this.getDao（）.save（entity）；

}

6、 根據(jù)id刪除

publicvoiddelete（Longid）{this.getDao（）.delete（id）；

}

7、 刪除所有

publicvoiddeleteAll（）{

this.getDao（）.deleteAll（）；

}

3.2.4 模型應(yīng)用

在業(yè)務(wù)邏輯BBL層，設(shè)計一個基于通用泛型的業(yè)務(wù)邏輯處理模型，完成整個項目的業(yè)務(wù)邏輯處理，最終達到大部分功能Nosql的實現(xiàn)。

在DAL層，設(shè)計基于Spring Data JPA的方法聲明即可，然后完成數(shù)據(jù)訪問。

模型應(yīng)用過程如圖3所示：

項目通過圖3Spring MVC Controller控制器，在BLL層找到對象對應(yīng)的模型邏輯業(yè)務(wù)處理接口，如果業(yè)務(wù)邏輯簡單，則進入DAL層進行數(shù)據(jù)訪問處理，再到ORM框架處理。否則進入Nosql模型，進行業(yè)務(wù)處理，模型處理完后找到對應(yīng)的數(shù)據(jù)訪問接口，最后通過SpringDataJPA選擇相應(yīng)的ORM框架處理即可，項目的功能即可完成。

項目應(yīng)用中泛型的模型設(shè)計舉例如下：

BLL層基于泛型的模型設(shè)計

publicabstractclassNosqlService

dsBaseDao

DAL層泛型基礎(chǔ)接口設(shè)計publicinterfaceBaseDaoextendsJpaRepository，paSpecificationExecutor

{}

3.2.5 模型評估

模型評估采用CoCoMo（Constructive CostModel）模型，中文為構(gòu)造性成本模型。它是一種精確、易于使用的，基于模型的成本估算方法，由Boehm提出[2?23]。模型評估數(shù)據(jù)來源完成同一項目的實際數(shù)據(jù)導(dǎo)出。其中一個表示同一項目未采用Nosql模型，一個是采用Nosql模型。采用所選取的樣本數(shù)據(jù)基本上具有如下的特征：1、相同的項目；2、選取基本上來源于人月的項目的數(shù)據(jù)，相同的人員素質(zhì)；3、使用相同的平臺，在同一個平臺開發(fā)所有的項目；4、開發(fā)所采用的語言以及項目所采用的管理流程相同。

CoCoMo模型，用于估算整個系統(tǒng)的工作量和軟件開發(fā)所需要的時間。

E=a（L）b （1）

D=cEd （2）

N=i （3）

其中：E表示工作量，單位是人月（PM）；

D表示開發(fā)時間，單位是月；

L是項目的代碼行估計值，單位是千行代碼；

N表示項目開發(fā)人數(shù)。

a、b、c、d是常數(shù)，取值如表1所示。

根據(jù)同一個項目開發(fā)的數(shù)據(jù)來源，一個未采用Nosql模型的代碼行數(shù)L=26.8千行代碼，與同一個項目采用Nosql模型的代碼行數(shù)L=15.6千行代碼進行評估。

由上述評估模型計算，得到的模型評估結(jié)果如表2所示：

其中：

A：同一個項目表示未采用Nosql模型。

B：同一個項目表示采用Nosql模型。

L：是項目的代碼行估計值，單位是千行代碼。

E：表示工作量，單位是人月（PM）。

D：表示開發(fā)時間，單位是月。

N：表示項目開發(fā)人數(shù)。

觀察表2，將未采用Nosql模型和采用Nosql模型開發(fā)的Web應(yīng)用進行比較，發(fā)現(xiàn)未采用Nosql模型開發(fā)的Web應(yīng)用，項目的代碼量總數(shù)較大，開發(fā)的時間周期較長，參與開發(fā)項目的人數(shù)較多。而采用Nosql模型的Web應(yīng)用，能夠以較少的代碼總數(shù)，用較短的開發(fā)周期以及較少的開發(fā)人員完成同樣的工作。綜上可以看出，采用Nosql模型開發(fā)Web應(yīng)用可以更加有效的提高軟件開發(fā)效率。

4 結(jié)論

針對項目代碼量大，代碼利用率低，開發(fā)效率低，提出了業(yè)務(wù)邏輯層的處理模型和數(shù)據(jù)訪問層的處理策略。首先介紹了BLL與DAL層泛型引入。然后，對基于JPA規(guī)范的Spring Data JPA的運用做說明。接下來，提出了基于JPA規(guī)范、泛型的業(yè)務(wù)邏輯處理模型，最后，對模型應(yīng)用做了介紹，并且對模型進行評估。通過該Nosql模型，使用者不知道具體的業(yè)務(wù)邏輯操作細節(jié)，通過業(yè)務(wù)邏輯需求，調(diào)用邏輯模型，完成業(yè)務(wù)邏輯操作。該模型要少量的代碼就可以實現(xiàn)業(yè)務(wù)邏輯操作和數(shù)據(jù)庫的訪問，從而使開發(fā)者可以更加專注于業(yè)務(wù)的分析，節(jié)省了開發(fā)人員熟悉項目架構(gòu)的時間，降低了項目開發(fā)的成本，提高了開發(fā)的效率。下一步工作將繼續(xù)研究如何在更復(fù)雜的個性化業(yè)務(wù)上，提供相應(yīng)的通用策略，促進項目更好，更快的開發(fā)。