業務邏輯層與數據訪問層的Nosql模型研究

吳勤 莊紅 鐵治欣 劉晶晶

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

關鍵詞：業務邏輯層；數據訪問層；通用泛型；JPA規范；SpnngDataJPA；Nosql模型中圖分類號：TP311.5文獻標識碼：ADOI：10.3969/j.issn.1003-6970.2017.08.008

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

引言

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

1 BLL與DAL層泛型引入

1.1 傳統BLL與DAL層設計

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

數據訪問層主要是封裝業務處理邏輯與數據存儲層之間的交互過程，向業務邏輯層提供數據服務。在具體的應用開發中，數據訪問層有多種不同的實現方式。業務模塊根據業務邏輯，調用對應DAO接口，實現接口，最后實現ORM。傳統業務邏輯層與數據訪問層的業務過程如圖1所示：

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

1.3 將Java泛型引入BLL與DAL層

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

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

2 基于JPA規范的SpringDataJPA的運用

2.1 JPA規范介紹

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

2.2 Spring Data JPA與JPA規范的關系

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

Spring Data JPA與JPA規范的關系如圖2所示：

3 BLL與DAL層設計基于Spring Data

JPA、通用泛型的模型實現

在項目開發中，以Java泛型與Spring Data JPA

為基礎，在業務邏輯層與數據庫訪問層構建Nosql模型。

3.1 相關配置

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

3.2 BLL層與DAL層的Nosql模型設計

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 模型思想

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

算法1分頁排序算法

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

//排序的對象集，為排序對象的集合，排序對象包括屬性和方向

返回值：Pageable型對象過程：

Begin

1、 Sortsort=null//倉1J建——個org.springframework.data.domain.Sort的sort排序對象

2、 If“排序的對象集”為空，排序根據數據庫id排序

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

4、 獲取“排序的對象集”的第一個排序對象屬性和方向

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

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

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

8、 for“排序的對象集”//從排序的對象集for第二個對象開發for循環直至結束

9、 獲取“排序的對象集”的下一個排序對象屬性和方向

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

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

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

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

End

算法2動態查詢條件拼接器算法

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

//key形如LIKE_topic，其中LIKE為操作，topic為操作字段，value為值?；蛘遦ey形如為EQ_user.name，其中EQ為操作，user.name為操作字段，user連接的子表，name為子表的字段名

過程：

Begin

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

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

3、 Forkey-value集合

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

繼續

5、 對value進行Java標準語言類型處理

6、 根據key分解出條件對象的屬性以及對應的value，賦值“條件對象”屬性

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

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

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

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

11、 創建一個javax.persistence.criteria.Predicate類型的predicates對象集合

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

13、 If“加入其他表對象標志”為join

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

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

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

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）；

“對象列值”轉化為對象列值數組

For對象列值數組

in=in.value（值）；

predicates.add（in）；

break；

case

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

break；

caseNOTNULL：

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

}

//將所有條件用and聯合起來

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最基本的數據訪問功能，對下面的幾個方面做詳細的使用介紹：1、Cmd Repository繼承Repository實現了一組增加刪除修改查詢相關的方法。

2、Paging And Sorting Repository繼承Cmd Repository，

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

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

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

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

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

1、 實現多功能排序查詢

publicListgetList（Map

Sortsort，finalClassclazz）{

Specificationspec=buildSpecification（searchParams，clazz）；

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

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

2、 實現多功能分頁查詢

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

Specificationspec=buildSpecification（searchParams，clazz）；

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

}

3、 實現列表查詢

publicListfindAll（）{

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

returnLists.newArrayList（iter）；}

4、實現排序列表查詢

publicListfindAll（Sortsort）{

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

returnLists.newArrayList（iter）；

}

5、 保存實體

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

}

6、 根據id刪除

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

}

7、 刪除所有

publicvoiddeleteAll（）{

this.getDao（）.deleteAll（）；

}

3.2.4 模型應用

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

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

模型應用過程如圖3所示：

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

項目應用中泛型的模型設計舉例如下：

BLL層基于泛型的模型設計

publicabstractclassNosqlService

dsBaseDao

DAL層泛型基礎接口設計publicinterfaceBaseDaoextendsJpaRepository，paSpecificationExecutor

{}

3.2.5 模型評估

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

CoCoMo模型，用于估算整個系統的工作量和軟件開發所需要的時間。

E=a（L）b （1）

D=cEd （2）

N=i （3）

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

D表示開發時間，單位是月；

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

N表示項目開發人數。

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

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

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

其中：

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

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

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

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

D：表示開發時間，單位是月。

N：表示項目開發人數。

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

4 結論

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