本發(fā)明涉及一種基于局域網(wǎng)的HDFS分布式文件共享系統(tǒng)，屬于互聯(lián)網(wǎng)
技術領域：
：。
背景技術：
：：在大數(shù)據(jù)的時代背景下，云存儲應用日漸廣泛，如微云、百度云盤等都是較為成熟的存儲工具。但是由于網(wǎng)絡帶寬的限制，對于較大文件的上傳耗時耗流量，同時無法及時獲取其他用戶的文件分享情況。當需要相應的文件資料時，需要通過相對復雜的途徑去獲取。而將文件保存于某一硬件設備上，數(shù)據(jù)安全依賴于硬件設備，隨著云計算技術在國內(nèi)外的高速發(fā)展，基于HDFS的技術得到了廣泛的應用。HDFS(HadoopDistributedFileSystem分布式文件系統(tǒng))的設計理念是存儲超大文件，所述超大文件是指數(shù)量級相對較大的文件，包括MB、GB、TB級。流式數(shù)據(jù)訪問：能夠進行高效的讀取，即一次寫入、多次讀取的方式，便于進行相應的Hadoop分析對象。在數(shù)據(jù)集生成以后，可以長時間在數(shù)據(jù)集上進行相應的分析工作。每一次分析會讀取該數(shù)據(jù)集的大部分甚至全部的數(shù)據(jù)，所以讀取所有的數(shù)據(jù)集時間上要比第一次記錄的時間要長。HDFS可以運行在普通廉價的服務器上，在硬件出現(xiàn)故障的情況下，也可以通過容錯策略來保證數(shù)據(jù)的高可用。HDFS具有的特點包括：(1)HDFS將文件保存成多個副本，提供了很好的容錯機制，副本丟失或者宕機的時候能夠進行自動恢復。默認保存三個副本。(2)能夠運行在廉價的機器上。(3)適合大數(shù)據(jù)的處理。Hadoop2.x中采用128M作為一個Block的塊大小。技術實現(xiàn)要素：本發(fā)明所要解決的技術問題是：實現(xiàn)文件的高速低費傳輸、存儲與分享。為解決上述技術問題，本發(fā)明提供一種基于局域網(wǎng)的HDFS分布式文件共享方法，包括以下步驟：1)將HDFS部署在局域網(wǎng)上，使用一臺服務器作為主節(jié)點(NameNode)，即應用的監(jiān)控服務器；使用其他N個服務器作為從節(jié)點(DataNode)，即應用的存儲服務器；2)在服務器端，主節(jié)點將文件分成固定大小的多個塊并存儲于不同的從節(jié)點存儲服務器上，且每個數(shù)據(jù)塊均有2-3個備份，保證了文件的安全性，同時系統(tǒng)可以很方便地增加從節(jié)點以實現(xiàn)橫向擴展，提高性能。穩(wěn)定高效的傳輸與存儲是指在局域網(wǎng)范圍內(nèi)部署HDFS，文件上傳后，主節(jié)點將文件分成多個副本存儲在不同的從節(jié)點服務器，實現(xiàn)分布式文件存儲的基本架構，將文件分片區(qū)、副本進行存儲，保證存儲文件不丟失。進一步地，將HDFS文件系統(tǒng)與WEB容器保存文件作為一個二級緩存，所有文件暫存到web服務器上，同時文件保存到HDFS上，讀取文件信息時，直接從web服務器上進行查找；若文件丟失，從HDFS上加載文件到web服務器上，以保證正常業(yè)務的進行。本發(fā)明實現(xiàn)了文件毫秒級查詢速度，系統(tǒng)采用二級文件系統(tǒng)，參照緩存機制的原理，二級文件系統(tǒng)保證了文件讀取的效率，使文件能夠穩(wěn)定快速的進行增刪改查的操作，提高了系統(tǒng)的讀寫效率和用戶體驗。進一步地，本發(fā)明的基于局域網(wǎng)的HDFS分布式文件共享方法包括用戶功能服務和文件功能服務：功能是在服務器端實現(xiàn)的，但是是通過webservice的方式開放接口供客戶端使用。所述用戶功能服務包括用戶注冊、登陸、好友管理；所述文件功能服務包括文件上傳、文件分享、文件管理；所述文件分享，用戶在客戶端發(fā)布一個分享文件的消息到服務器端，然后存入MongoDB數(shù)據(jù)庫，并允許用戶指定分享文件集的封面、描述以及文件列表等，數(shù)據(jù)通過客戶端上傳服務器，經(jīng)服務器處理后存入MongoDB數(shù)據(jù)庫。所述文件管理，包括新建目錄、上傳文件、下載文件、刪除文件等基本操作，采用文件操作節(jié)點搜索算法(FilePrivateDtoOperate)實現(xiàn)文件管理功能。文件目錄與文件的關系由Json的樹形格式表示，所以系統(tǒng)采用深度優(yōu)先遍歷算法查詢指定的樹形節(jié)點，查找到相應的樹形節(jié)點后，對該節(jié)點進行相應的操作，即可實現(xiàn)對文件的各種操作，基本操作過程為：(1)查詢得到該用戶的原有文件的樹形結構；(2)輸入?yún)?shù)，根據(jù)操作類型的不同，選擇輸入文件的源序列碼和目標序列碼；(3)采用深度優(yōu)先搜索方法(DFS)找到目標節(jié)點；(4)對目標節(jié)點進行相應操作。根據(jù)操作的不同，將操作類型分為：新增append、移動remove、查找search、重命名rename。利用四個基本的操作即可組裝成所有的文件操作。例如，如果想新增一個文件夾，先使用DFS查找到相應的節(jié)點，在該節(jié)點下append一個新的序列碼，即可完成在文件夾下新增一個文件夾的功能。再例如，如果想查找到某個文件夾下的所有的文件及其目錄信息，那么使用search操作，找到指定文件夾的序列碼，返回該節(jié)點下所有的privateFileDtoList數(shù)據(jù)結構即可。進一步地，本發(fā)明結合Mysql、MongoDB兩者數(shù)據(jù)庫進行不同類別數(shù)據(jù)的存儲：用戶數(shù)據(jù)及好友關系數(shù)據(jù)存于Mysql數(shù)據(jù)庫，文件地址序列化服務產(chǎn)生的文件地址索引、共有文件索引、文件用戶關系、用戶文件關系、分享文件等信息存放于MongoDB數(shù)據(jù)庫；同時利用HDFS進行文件數(shù)據(jù)(包括上傳文件、文件地址)的存儲，極大提高了數(shù)據(jù)的存取效率。由于MongoDB數(shù)據(jù)庫本身不支持類似于關系型數(shù)據(jù)庫的事務，為了能夠保證業(yè)務的完整性，本發(fā)明通過編程邏輯模擬關系型數(shù)據(jù)庫中的事務，從而解決MongoDB數(shù)據(jù)庫中數(shù)據(jù)一致性的問題。在MongoDB數(shù)據(jù)庫中建立一張事務表(TRANSACTION表)，事務表存放以下內(nèi)容：(1)_id：事務記錄唯一的id號，又稱transactionId；(2)dealType：事務狀態(tài)，取值為0-4，分別表示為：初始態(tài)init、運行態(tài)process、完成態(tài)commit、終止態(tài)complete、取消態(tài)cancel五個狀態(tài)；(3)IsRollBBack：事務回滾標識符，取值0或1，0表示事務不需回滾，1表示事務需回滾；(4)CreatedData：事務創(chuàng)建時間；(5)stateDate：上一次狀態(tài)改變時間；(6)CriticalDataDtoList：用于支持多節(jié)點事務處理，其中stage表示節(jié)點，processDataDtoList表示事務所需數(shù)據(jù)，包括待處理的表名(tableName)、數(shù)據(jù)主鍵(primaryKey)、數(shù)據(jù)內(nèi)容(data)、操作方式(operType)，operType可取值C(新增數(shù)據(jù))、U(修改數(shù)據(jù))、D(刪除數(shù)據(jù))。為支持事務的多線程使用，提高運行效率，本發(fā)明利用一個線程池來管理事務管理器，線程池的本質是一個容器Context，用于保存程序執(zhí)行的上下文。例如：node1(transactionId)—>nodel2(transactionId)，即第一節(jié)點將transactionId傳遞給第二節(jié)點，兩個節(jié)點共同處理同一條事務記錄，提高運行效率。同時用堆棧的方法來存儲事務管理器，即put、get、pop、release方法。建立MongoDB數(shù)據(jù)庫事務框架，MongoDB數(shù)據(jù)庫事務框架建立過程包括以下步驟：步驟1：初始化事務，在MongoDB數(shù)據(jù)庫中生成一條事務記錄，初始化事務的狀態(tài)(dealType)為init，并通過序列化生成一個唯一的12字節(jié)的節(jié)點transactionId；步驟2：將關鍵數(shù)據(jù)存入MongoDB數(shù)據(jù)庫事務表的processDataDtoList中，在操作數(shù)據(jù)表記錄后添加節(jié)點transactionId，即對該事務進行加鎖，其他數(shù)據(jù)操作等待該事務完成解鎖后，才能執(zhí)行，同時把節(jié)點transactionId傳給其他節(jié)點，進行多線程并行處理；步驟3：計算上一次狀態(tài)改變時間(stateDate)和事務創(chuàng)建時間(CreatedData)的時間差，若超過設定值，如100ms，即判斷事務失敗(部分數(shù)據(jù)已經(jīng)成功處理并解鎖，但沒有完成所有處理)，則執(zhí)行步驟5，若事務執(zhí)行成功，即在設定值100ms內(nèi)事務狀態(tài)更改為commit態(tài)，則執(zhí)行步驟6；步驟4：將IsRollBBack置為1，對事務進行回滾，根據(jù)事務表processDataDtoList中的數(shù)據(jù)，找到待操作的所有數(shù)據(jù)記錄，回滾操作即重新對已處理的數(shù)據(jù)記錄重新加鎖；步驟5：若事務不斷回滾超過設定次數(shù)，如5次，即認為該事務不可完成，將事務狀態(tài)置為cancel態(tài)，還原數(shù)據(jù)表內(nèi)容，對數(shù)據(jù)記錄進行解鎖，刪除該條事務記錄，同時在客戶端進行提醒；步驟6：若事務完成，即可將事務狀態(tài)置為complete狀態(tài)，并銷毀該條事務記錄，加快事務查詢速率；步驟7：結束。本發(fā)明達到的有益效果：本發(fā)明將HDFS部署在局域網(wǎng)上，局域網(wǎng)上傳文件速度快，不費流量，HDFS可以保證在存在故障的情況下也能可靠地存儲數(shù)據(jù)；本發(fā)明利用二級文件系統(tǒng)，進一步保證文件安全性，并實現(xiàn)文件的毫秒級查詢效率；利用不同類型的數(shù)據(jù)庫存儲不同類型的數(shù)據(jù)，提高數(shù)據(jù)存取效率，同時利用MongoDB事務框架保證事務數(shù)據(jù)的完整性；本發(fā)明設有界面友好的客戶端，方便客戶進行個性化的文件管理、文件分享，極大地提高了用戶體驗。附圖說明圖1系統(tǒng)C/S架構的邏輯調(diào)用關系圖；圖2系統(tǒng)客戶端具體模塊功能結構圖；圖3系統(tǒng)服務器端框架構圖；圖4模塊存儲位置的邏輯圖；圖5系統(tǒng)服務器端MongoDB事務框架建立過程流程圖；圖6MongoDB關鍵數(shù)據(jù)的存放方式示意圖；圖7系統(tǒng)服務器端文件二級緩存的基本架構圖；圖8系統(tǒng)服務器端文件服務類圖；圖9系統(tǒng)服務器端深拷貝程序流程圖；圖10系統(tǒng)服務器端實體斷言測試框架流程圖。具體實施方式本發(fā)明依靠基于局域網(wǎng)的HDFS分布式文件共享系統(tǒng)來實現(xiàn)，本系統(tǒng)包括客戶端和服務器端兩個部分。下文將結合附圖進行詳細說明。根據(jù)系統(tǒng)功能的劃分，決定使用C/S架構進行實現(xiàn)。如圖1所示：客戶端：使用HTTP請求調(diào)用相應的服務器端所開放的Webservice接口，達到處理數(shù)據(jù)的目的。本發(fā)明的客戶端采用Android系統(tǒng)作為基礎，實現(xiàn)服務器端接口調(diào)用及用戶輸入處理的作用?？蛻舳苏{(diào)用服務器端接口都是以HTTP請求的方式，傳遞數(shù)據(jù)的格式均為Json格式的數(shù)據(jù)，采用AndroidHTTP請求框架okHttp作為基礎的開發(fā)程序包，封裝實現(xiàn)了okHttpUtils的編寫。在用戶發(fā)布或者上傳數(shù)據(jù)時，客戶端系統(tǒng)會發(fā)送相應的數(shù)據(jù)到服務器端指定的接口，實現(xiàn)相應的業(yè)務邏輯?？蛻舳说哪K具體服務功能如圖2?？蛻舳嘶贏ndroid進行界面設計，文件存儲服務作為本系統(tǒng)的核心服務于在客戶端中廣泛使用，本文展示部分文件功能設計界面。服務器端：主要用于處理客戶端的不同請求，保證事務的完整性與數(shù)據(jù)的安全性，提供一個能夠實現(xiàn)用戶與用戶之間即時通訊的接口，并提供相應的Webservice接口供客戶端進行調(diào)用。根據(jù)擴展的需求，如圖3所示，本發(fā)明將系統(tǒng)的服務器端抽象為三層進行設計，主要為操作系統(tǒng)層、服務器層、接口層。對于每一層，基本定位為：操作系統(tǒng)層：系統(tǒng)所使用的組件相對復雜，所以使用Linux作為底層的操作系統(tǒng)。應用層：應用層分成了數(shù)據(jù)庫服務器、應用服務器、文件服務器以及監(jiān)控日志服務器等。其中數(shù)據(jù)庫服務器選擇使用MySQL數(shù)據(jù)庫與MongoDB數(shù)據(jù)庫來進行存儲，數(shù)據(jù)存儲位置分布如圖4：使用MySQL數(shù)據(jù)庫保存用戶數(shù)據(jù)以及用戶好友關系，即在MySQL表中建立用戶表(user)和好友關系表(friend)。使用MongoDB數(shù)據(jù)庫保存文件地址序列化服務產(chǎn)生的文件地址索引、公有文件索引、文件用戶關系、用戶文件關系、分享文件數(shù)據(jù)數(shù)據(jù)，數(shù)據(jù)表建設情況。由于MongoDB數(shù)據(jù)庫本身不具備事務，為保證MongoDB數(shù)據(jù)的完整性，本發(fā)明設計一個相應的事務框架來保證整個任務在執(zhí)行的過程中事務具有一致性。需要在MongoDB數(shù)據(jù)庫中建立一張事務表，事務表主要存放以下內(nèi)容：(1)_id：即事務記錄唯一的id號，又稱transactionId；(2)dealType：即事務狀態(tài)，取值為0-4，分別表示init(初始態(tài))、process(運行態(tài))、commit(完成態(tài))、complete(終止態(tài))、cancel(取消態(tài))五個狀態(tài)；(3)IsRollBBack：即事務回滾標識符，取值0或1，0表示事務不需回滾，1表示事務需回滾；(4)CreatedData：事務創(chuàng)建時間；(5)stateDate：上一次狀態(tài)改變時間；(6)CriticalDataDtoList：用于支持多節(jié)點事務處理。其中stage表示節(jié)點，processDataDtoList表示事務所需數(shù)據(jù)，包括待處理的表名(tableName)、數(shù)據(jù)主鍵(primaryKey)、數(shù)據(jù)內(nèi)容(data)、操作方式(operType)，operType可取值C(新增數(shù)據(jù))、U(修改數(shù)據(jù))、D(刪除數(shù)據(jù))。為支持事務的多線程使用，提高運行效率，本發(fā)明引入一個線程池來管理事務管理器，線程池的本質是一個容器，用于保存程序執(zhí)行的上下文，定義為Context。例如：node1(transactionId)—>nodel2(transactionId)，即第一節(jié)點將transactionId傳遞給第二節(jié)點，兩個節(jié)點共同處理同一條事務記錄，提高運行效率。同時用堆棧的方法來存儲事務管理器，即put、get、pop、release方法。MongoDB事務框架的建立過程包括以下步驟，MongoDB事務框架建立過程如圖5所示：步驟1：初始化事務，在MongoDB數(shù)據(jù)庫中生成一條事務記錄，初始化事務的狀態(tài)(dealType)為init，并通過序列化生成一個唯一的12字節(jié)的transactionId；步驟2：將關鍵數(shù)據(jù)存入事務表processDataDtoList(如圖6)中，在操作數(shù)據(jù)表記錄后添加transactionId，即對該事務進行加鎖，其他數(shù)據(jù)操作必須等待該事務完成解鎖后，才能執(zhí)行，同時把transactionId傳給其他節(jié)點，進行多線程并行處理；步驟3：計算上一次狀態(tài)改變時間(stateDate)和事務創(chuàng)建時間(CreatedData)的時間差，若超過100ms，即判斷事務失敗(部分數(shù)據(jù)已經(jīng)成功處理并解鎖，但沒有完成所有處理)，則執(zhí)行步驟5；若事務執(zhí)行成功，即在100ms內(nèi)事務狀態(tài)更改為commit態(tài)，則執(zhí)行步驟6；步驟4：將IsRollBBack置為1，對事務進行回滾，根據(jù)processDataDtoList中的數(shù)據(jù)，找到待操作的所有數(shù)據(jù)記錄，回滾操作即重新對已處理的數(shù)據(jù)記錄重新加鎖；步驟5：若事務不斷回滾超過5次，即可認為該事務不可完成，將事務狀態(tài)置為cancel態(tài)，還原數(shù)據(jù)表內(nèi)容，對數(shù)據(jù)記錄進行解鎖，刪除該條事務記錄，同時在客戶端進行提醒；步驟6：若事務完成，即可將事務狀態(tài)置為complete狀態(tài)，并銷毀該條事務記錄，加快事務查詢速率；步驟7：結束。在應用服務器中，根據(jù)功能點的要求主要包括Tomcat服務器。其中Tomcat服務器是整個web服務的容器，用于供外部的應用訪問服務器的資源。其中包括4個主要的服務，分別為用戶服務、文件存儲服務、社會化服務、文件地址序列化服務。在文件存儲服務，是本設計的重點，需要實現(xiàn)海量級的文件存儲與毫秒級的文件查詢，流暢的文件操作時本設計的特點之一。采用二級緩存的方式實現(xiàn)毫秒級的文件查詢。基本構架如圖7所示，在本系統(tǒng)中，參照緩存機制的原理，將HDFS文件系統(tǒng)與WEB容器保存文件作為一個二級緩存。保存在WEB服務器上面的文件可能會因為一些特殊情況而被銷毀，但是在HDFS上的文件不會被銷毀?？蛻舳苏埱笠粋€相應的文件地址后，服務器端回調(diào)用相應的服務，首先到WEB服務器的文件系統(tǒng)上查看該文件是否存在。如果文件存在，將會寫回這個文件到客戶端。如果文件不存在，將會到MongoDB服務器，根據(jù)傳入進來的WEB服務器的文件地址而查詢到HDFS上(WEB服務器文件地址作為主鍵，查詢效率很高)的文件，從HDFS上加載到WEB服務器。這個過程的加載時間基本可以忽略不計(因為文件可能在同一個ACK上)。加載完成之后，同樣的會將這個文件寫到客戶端。即所有文件會保存到web服務器上，但是同時文件也會保存到HDFS上。針對于web服務器的文件，由于可能丟失，此時可以根據(jù)文件的保存地址到HDFS上重新加載相應的文件到web服務器上，通過這樣的方式保證了文件的安全性以及毫秒級的查詢速度。流暢的文件操作依靠節(jié)點搜索算法實現(xiàn)：文件的操作主要包括新建目錄、上傳文件、下載文件、刪除文件等基本操作。因為本發(fā)明采用Json的樹形格式去表示文件目錄與文件的關系，所以采用深度優(yōu)先遍歷去查詢指定的樹形節(jié)點。在查找到相應的樹形節(jié)點后，只需要對這個節(jié)點進行相應的操作即可?；静僮鬟^程為：1、查詢得到該用戶的原有文件的樹形結構。2、入?yún)?，根?jù)操作類型的不同，選擇輸入文件的源序列碼和目標序列碼。3、DFS找到目標節(jié)點。4、對目標節(jié)點進行相應操作。根據(jù)操作的不同，將大致的操作類型分為：append、remove、search、rename。利用四個基本的操作即可組裝成所有的文件操作需要。例如，想要新增一個文件夾，先使用DFS(類圖如圖8)查找到相應的節(jié)點之后，在該節(jié)點下append一個新的序列碼，即可完成在文件夾下新增一個子文件夾的功能。再例如，如果想查找到某個文件夾下的所有的文件及其目錄信息，則使用search操作，找到指定的文件夾的序列碼，返回該節(jié)點下的所有的privateFileDtoList的數(shù)據(jù)結構即可。針對不同的文件操作，實際操作的過程是需要通過組合來完成的。定義四個基本的操作方法，借助上述DFS的搜索算法，定義出四個基本的操作類型：append、remove、search、rename。在具體操作時，通過搜索可以得到一個查詢到的節(jié)點的序列碼、父節(jié)點的序列碼，就可以對特定的序列碼文件進行相應的操作。監(jiān)控與日志的服務器作為保證系統(tǒng)穩(wěn)定性及可用性的支撐部分，需要建立在應用層的與其他部分平行的部分，但是這一部分與其他的應用服務器沒有關聯(lián)，也就是說能夠獨立的進行。日志部分采用SLF4J來進行處理，使用Flume進行分析；對于應用服務器的狀態(tài)，使用Spring-Boot-actuator進行監(jiān)聽。APIGatewayAPIHanlder：最上面一層的是開放出去的一些接口及請求的轉發(fā)器。通過應用服務的構建，本發(fā)明已經(jīng)具備了大量可以供外部使用的接口。需要通過接口層將服務發(fā)布到相應的http地址上。本發(fā)明采用spring4中的RestController來實現(xiàn)該層，并且通過自定義的Dispather來處理請求的轉發(fā)，綁定相應的api地址到指定的http地址上，從而在web容器的運行下，使客戶端能訪問到相應的資源。由上述的所有組件共同構成了服務器端的完整架構，支撐整個服務器端的執(zhí)行。本發(fā)明利用深拷貝實現(xiàn)客戶端與服務器端的數(shù)據(jù)交換：通過客戶端傳遞過來的HTTP請求無法根據(jù)需要封裝成一個完整的對象傳遞到服務器端。所以，需要用傳遞過來的鍵值對類型數(shù)據(jù)進行封裝，使之成為能在服務器端進行操作的實體類對象。但是從上述的情況來看，目前所處理的數(shù)據(jù)結構相對較多，如果對于每一個數(shù)據(jù)結構都特化的重寫一個封裝的方法，那么源碼量會過于復雜，不便維護。本發(fā)明利用深拷貝的特點，通過反射技術將這些封裝的過程抽象成一個通用的方法。除了通過HTTP請求過來的數(shù)據(jù)，部分數(shù)據(jù)也需要進行相應的封裝。因為在Java中，當使用另一個對象的數(shù)據(jù)時，如果不是逐一賦值，將無法得到一個新的對象實例，而是得到一個對象的引用。此時，也需要使用到深拷貝技術。因此，綜合上述兩點，需要設計一個通用的思路，去處理HTTP與對象之間的深拷貝的工具類。編碼過程中需要使用到Java的反射機制(為一個包)，對于Http請求中的參數(shù)，其中包含了一個鍵值對的Map集合，Map集合中有多個通過Http請求需要的參數(shù)，其中包含了封裝目標的參數(shù)。因此，需要從封裝目標的參數(shù)中得到相應的數(shù)據(jù)，然后依次遍歷所有的參數(shù)，再去Map集合中尋找是否存在相應的字段，如果存在，則通過反射機制對相應的字段進行賦值。程序流程圖如圖9所示。在處理兩個對象的深拷貝時，需要先對相應的字段進行過濾，即方法中包含get為前綴的字段。則需要設計一個字段的過濾器，該過濾器主要用于過濾方法中不包含get為前綴的方法，剩下的方法即為該方法的字段。過濾完成后，返回的是一個包含所有get方法的Map集合。下一個階段對于Http的深拷貝與對象之間的深拷貝有差別，但是處理的過程基本類似，不同點在于入?yún)⒉煌Ｍ粋€類型的對象字段一定相同，所以只需要對它們共同的類進行過濾，得到的結果相同。然后使用reflect對它們的所有的字段進行賦值，即可完成這一次的深拷貝。程序的流程僅在處理賦值之前加上過濾操作即可。整個設計實現(xiàn)后，本發(fā)明設計了實體斷言測試框架進行系統(tǒng)測試。在進行單元測試時，很難準確判斷存儲到數(shù)據(jù)庫的數(shù)據(jù)是否和構造階段構造出來的數(shù)據(jù)相同，使用junit進行測試只能對于某一種基本數(shù)據(jù)類型進行測試，但是無法知道實體對象中每一個字段的數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)是否相等。此時需要自定義一個測試框架，來對特定的程序對象與數(shù)據(jù)庫對象進行比較。編寫過程同樣需要用到深拷貝技術的實現(xiàn)思路。入?yún)閮蓚€實體，這兩個實體要求是同一個類型，否則這兩個對象的比較沒有意義。返回值是一個AssertBeanParam，表示這兩個對象數(shù)據(jù)相同的個數(shù)、不同的個數(shù)、相同的數(shù)據(jù)字段及具體值、不同的數(shù)據(jù)字段及具體值。實現(xiàn)過程不應該借助于其他的框架，采用標準JDK進行編寫。服務器端實體斷言測試實現(xiàn)的過程為(如圖10所示)：1、實例化一個AssertBeanParam為后續(xù)數(shù)據(jù)返回進行準備；2、判斷輸入的兩個實體參數(shù)的類型是否相同；3、過濾，使用filterGetMethod，得到所有的字段；4、通過反射處理，得到這兩個對象的具體數(shù)據(jù)；5、判斷每一個字段的數(shù)據(jù)是否相等，若相等，則實體內(nèi)的Map集合中，正確標號successCount加1，并將相等數(shù)據(jù)存入successMap數(shù)據(jù)集中；若不相等，則錯誤標號errorCount加1，并將不相等數(shù)據(jù)存入errorMap數(shù)據(jù)集中；對于數(shù)值，將數(shù)值的返回格式統(tǒng)一定義為：dstValue：dstValue,srcValue：srcValue，數(shù)值是一個字符串類型；6、返回AssertBeanParam。以上描述了本發(fā)明的具體模塊設計及優(yōu)點。本行業(yè)的技術人員應該了解，本發(fā)明不受上述實例的限制，上述實例和說明書中描述的只是說明本發(fā)明的思想，在不脫離本發(fā)明技術方案精神和范圍的前提下，本發(fā)明還會有各種變化和改進，這些變化和改進都落入要求保護的本發(fā)明范圍內(nèi)。本發(fā)明要求保護范圍由所附的權利要求書及其等效物界定。當前第1頁1 2 3 當前第1頁1 2 3