基於SSM框架賀州學院校園二手交易平臺設計與實現
註:畢業有一段時間了,這裏了做一下當年畢設的經驗分享。
緒論
隨著中國新四大發明的誕生,網購成了千千萬萬網友們購物的新方式,新的購物方式促進商業的發展,但隨著人們生活水平的提高,許多新購置的物品用了沒多少天,甚至沒多少次就開始嫌棄、就開始不再使用,成為了閑置物品,大量的閑置物品已然爆發式增長。
在網購人群中,學生網購已經是非常常見,隨著購物的便捷,學生們四年下來手裏頭有著太多的閑置的廢舊物,一到大四畢業季,學生離校時都會丟棄一些學習資料和生活用具,這些閑置的廢舊物造成校園垃圾增長,給環境保潔員工作帶來極大的壓力,更是造成了資源浪費。作為本屆的畢業生我深有體會。
而現在網上主流的二手交易平臺“閑魚”、“轉轉”,更多的是面向同城交易、國內外交易,缺乏一個面向學生群體的二手交易平臺,而學生消費群體,一到每年的畢業季大量的閑置物品無法及時處理,而想要購置二手物品的大一、大二等同校的同學由於缺乏途徑,並不知道那個學長學姐有哪些閑置的物品。如果學校有一個自己的校園二手交易平臺,而已發布者身份真實明確,就是我們學校的學生,那我們的學弟學妹就可以直接在我們學校自己的校園二手交易平臺上購置同校友發布的閑置物品,方便又安心,而對於我們畢業生來說,直接把閑置物品放在我們自己學校的二手交易平臺,直接在校園內就能交易,方便快捷、省心省事。
對於每一個即將離校的學生來說,無論之前是如何的嫌棄學校的各種不好,抱怨飯堂的有多不好吃,到了要離開的時候,多少都是有點舍不得。而通過二手交易平臺,把回憶留給校園,閑置物品留給學弟學妹,還能換一張離去的車票,一舉多得!
摘要
本平臺采用分布式系統架構,擬定有以下幾個模塊:後臺子系統:管理員按權限職能不同,可以分別對平臺進行不同程度的管理、維護等。門戶子系統:solr搜索、瀏覽、登錄註冊、個人中心、發布閑置/求購、學生身份認證等。服務層子系統:為了方便以後對平臺進行擴展,將一些公用的、常用的操作提到服務層。同時,對項目中所用到的知識點進行簡單介紹。
平臺的特色及創新點
1、SSM框架開發,數據庫使用MySQL,整個項目進行分布式架構,降低了平臺的耦合度,對某個功能修改或增加新功能,都不會對其它功能模塊產生影響,將傳統部分功能拆分出來,形成各個獨立的子系統。各子系統之間都是以服務的形式提供API接口給其他模塊調用
2、使用solr搜索引擎、搭建nginx圖片服務器、單機版redis緩存數據庫,大大提高效率,以應付高訪問,高並發(美中不足的是沒有搭建集群做高可用)
3、使用學校教務系統賬號進行賀州學院學生身份認證(通過HttpClient模擬登陸),發布者身份信息真實、平臺由學生(可以跟計算機協會合作,由他們進行維護)維護,平臺安全可靠
4、註冊時使用手機短信註冊,每個手機號只能註冊一次,忘記密碼時,可以選擇手機找回或郵箱賬號(需綁定)
平臺架構圖:
數據字典
(1)用戶表t_user如表3.2.1所示。
表3.2.1 用戶表t_user
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
username |
varchar |
|
用戶名 |
password |
varchar |
|
密碼 |
phone |
int |
|
電話號碼 |
eamil |
varchar |
|
郵箱 |
credit |
int |
|
信用度/10-100 |
register_time |
varchar |
|
註冊時間 |
login_time |
varchar |
|
最近登錄時間 |
login_city |
varchar |
|
最近登錄城市 |
logout_time |
varchar |
|
退出時間:用於掃描聊天表 |
chat_id |
varchar |
外鍵 |
聊天表id 之間用“,”隔開 |
is_authentication |
int |
|
是否身份認證/0否1是 |
status |
int |
|
0註銷/1正常/-1凍結 |
(2)用戶信息表t_user_datum如表3.2.2所示。
表3.2.2 用戶信息表t_user_datum
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
user_id |
int |
外鍵 |
t_user表的id |
name |
varchar |
|
真實姓名 |
idcard |
varchar |
|
身份證號 |
birthdate |
varchar |
|
出生日期 |
gender |
int |
|
性別 / 0女1男 |
xh |
int |
|
學號 |
xy |
varchar |
|
學院 |
zy |
varchar |
|
專業 |
bj |
varchar |
|
班級 |
tx |
varchar |
|
頭像圖片存放路徑 |
(3)出售表t_sell如表3.2.3所示。
表3.2.3 出售表t_sell
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
user_id |
int |
外鍵 |
發布用戶id |
type |
int |
外鍵 |
商品類型id |
title |
varchar |
|
標題 |
describe_ |
text |
|
描述 |
photos |
varchar |
|
圖片/json格式可存多張 |
price |
varchar |
|
轉讓價格 |
original_price |
varchar |
|
原價 |
release_time |
varchar |
|
發布時間 |
browse_count |
int |
|
瀏覽次數 |
status |
int |
|
-1審核失敗/0審核中/1正常/2下架 |
(4)求購表t_purchase如表3.2.4所示。
表3.2.4 求購表t_purchase
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
user_id |
int |
外鍵 |
發布用戶id |
type |
int |
外鍵 |
求購商品類型id |
title |
varchar |
|
標題 |
describe_ |
text |
|
描述 |
price |
varchar |
|
求購價格 |
release_time |
varchar |
|
發布時間 |
browse_count |
int |
|
瀏覽次數 |
status |
int |
|
-1審核失敗/0審核中/1正常/2下架 |
(5)商品類型表t_type如表3.2.5所示。
表3.2.5 商品類型表t_type
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
name |
varchar |
|
類型 |
is----_parent |
int |
|
是否父類 |
parent_id |
int |
外鍵 |
父類id/商品類表id |
(6)後臺管理員表t_admin如表3.2.6所示。
表3.2.6 後臺管理員表t_admin
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
username |
varchar |
|
用戶名 |
password |
varchar |
|
密碼 |
level |
int |
|
等級 |
(7)熱門推薦表t_recommend如表3.2.7所示。
表3.2.7 熱門推薦表t_recommend
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
type |
int |
外鍵 |
商品類型id |
is_vip |
int |
|
0 普通推薦/1 VIP推薦 |
flag |
int |
|
0求購/1閑置 |
item_id |
int |
外鍵 |
商品id |
img |
varchar |
|
商品圖片 |
title |
varchar |
|
商品標題 |
price |
varchar |
|
轉讓價 |
(8)廣告推廣表t_ad如表3.2.8所示。
表3.2.8 廣告推廣表t_ad
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
position_id |
int |
外鍵 |
廣告位置表id |
img |
varchar |
|
圖片地址 |
location |
varchar |
|
鏈接地址 |
title |
varchar |
|
標題 |
(9)聊天記錄表t_chat如表3.2.9所示。
表3.2.9 聊天記錄表t_chat
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
text |
varchar |
|
消息內容/json格式追加 |
user_user |
varchar |
|
聊天的兩個人(_隔開) |
update_time |
varchar |
|
更新時間(只保存七天) |
(10)廣告位置表t_ad_position如表3.2.10所示。
表3.2.10 廣告位置表t_ad_position
列名 |
類型 |
主外鍵 |
備註 |
id |
int |
主鍵/自增 |
表唯一id |
position |
varchar |
|
廣告位置 |
is_parent |
int |
|
是否父類 |
parent_id |
int |
|
父類id/廣告位置表id |
平臺功能實現
註冊功能實現
協議閱讀展示
使用layer框架iframe父子操作層;a標簽觸發js自定義函數,彈窗展示。
MD5對註冊密碼加密、存儲密文
使用封裝好的MD5Util.java傳入一個明文,返回一個32位的密文,將用戶註冊密碼MD5加密後保存到數據表t_user。
登陸表單非空、正則的前端驗證
使用封裝好的js checkform方法 返回參數是Boolean類型,獲取表單上的信息並傳入checkform中,如果為空、不匹配給定的正則,返回false,否則返回true;在ajax beforeSubmit中使用;如果整個beforeSubmit方法返回false則不提交表單,反之提交。
手機短信驗證註冊
購買阿裏雲市場的短信驗證API,價格也比較便宜4元/100次,購買成功後會生成一個AppCode,調用提供的API是傳入skin短信模板(想要使用自定義的短信模板需要申請購買,我這裏使用供應商提供的短信模板),code驗證碼,phone手機號碼,然後在header請求頭中設置Authorization傳入這樣的格式的值:"APPCODE "+AppCode。驗證碼是一個4位數的隨機數,如果發送成功,則在響應回來的json中code為OK。頁面中點擊“免費獲取驗證碼”觸發sendSMS事件,在通過表單驗證後執行seanSMS.do,用戶在有效期間內輸入正確的短信驗證碼則能通過註冊驗證。
用戶唯一驗證
持久化存儲中,平臺要求不得出現重復的用戶名跟註冊的電話號碼,所以註冊時先查詢是否已經有同樣的用戶名,有則返回用戶名已存在。一個手機號碼只能註冊一次,已經註冊過的手機號碼不允許重復註冊。
註冊
通過表單驗證後攜帶參數調用register.do,獲取當前時間設置成註冊時間,並將是否身份認證設置成0/否,並直接調用mybatis逆向工程生成的mapping代理類的insert方法插入數據庫中,並返回註冊成功
登錄功能實現
服務端圖形驗證碼
使用擴展包validate/image.jsp;訪問該jsp,在session設置rand;在我們的action中取得session作用域中rand的值跟前端表單輸入的驗證碼判斷是否匹配即可。
密碼登錄
通過表單驗證後攜帶form參數請求login.do,後臺獲取session中的驗證碼同時判斷是否為自動登錄,如果是自動登錄直接跳過驗證碼環節,從cookie中取出用戶名跟密碼並將密碼MD5加密後去用戶表t_user去匹配,匹配正確則把用戶信息存到session中並返回登錄成功。同時,把登錄用戶的信息保存到redis緩存數據庫中,redis的key同時要在存到用戶的cookie中。每次跳轉特定頁面(用戶管理頁面、發布商品頁面、找回密碼、身份認證等)時都想去檢查redis中是否還有數據,如果沒有這跳轉登錄頁面。
cookie記住密碼
使用cookie客戶端技術,當用戶時,把用戶輸入的密碼MD5加密後使用密文去跟數據庫匹配,一致則登錄成功,登錄成功後後臺判斷表單提交時是否勾選‘記住密碼’跟‘七天免登陸’如果勾選設置cookie在客戶端保存用戶名、密碼、autologin標識,如果勾選了‘七天免登陸’默認記住密碼。
七天免登陸
前端jsp界面使用jstl if標簽判斷cookie是否有對應的值如果有用戶名、密碼則放到對應input標簽value中並勾選上‘記住密碼’;如果有autologin標識,則自動提交登陸表單,後臺判斷是否為自動登錄,是則跳過圖形驗證。
JavaMail通過綁定郵箱找回密碼;
使用JavaMail技術,導入對應jar包:mail-1.4.jar;選擇一個開啟了SMTP服務的郵箱作為用來發送郵件的郵箱,在自定義類JavaMail.java中配置詳細參數,設置授權碼。在需要發送郵件的action中調:JavaMail.fireMail()方法,有兩個參數receiveMailAccount 用戶郵箱、verification 後臺隨機生成的四位數字;如果用戶不存在、郵箱不是用戶綁定郵箱則提示。通過驗證碼後跳到輸入新密碼頁面,用戶輸入信息後請求後臺MD5加密後存起來即可。
短信登錄
邏輯是這樣的,首先去數據庫匹配綁定當前手機號的用戶是否存在,存在才能繼續下面的操作;其次調用發送短信的seanSMS.do方法發送登錄驗證碼到用戶手機中,同時存到session中;最後,form表單攜帶手機號,短信驗證碼請求後臺,如果匹配則返回登錄成功的結果集(跟密碼登陸差不多,不同的是不用對記住密碼、七天免登陸進行操作)
短信找回密碼
因為一個賬號只能綁定一個手機號碼,同時用戶名是唯一的,所有頁面中我直接讓用戶輸入手機號碼,點擊發送短信時後臺要判斷是否有綁定該手機號的用戶存在,存在則發送找回密碼驗證碼,並存到session中。通過驗證碼後跳到輸入新密碼頁面,用戶輸入信息後請求後臺MD5加密後存起來即可。
首頁展示
中間大廣告輪播
中間的圖片輪播使用layui的旋轉木馬,正確引入layui框架後將父類div的class設置為layui-carousel,子類div聲明carousel-item屬性,然後在子類div中的孩子圖片節點就是能實現輪播效果。首先在頁面加載的時候ajax請求後臺獲取圖片路徑(為了增加系統效率,先去redis緩存查找,如果redis中沒有則去數據庫查詢,然後放到redis中,使用廣告位置id作為key,字符串”AD”作為field)append到子類div中,並設置a標簽跳轉路徑跟title即可,這裏有一點要註意的是需要設置成同步,否則有時候標簽追加上去但沒有顯示。
商品類型分類
商品類目使用ul實現,首先先查出所有的父類類型分類,當鼠標滑到對應的li時觸發mouseenter改變li的背景顏色同時請求後臺根據父類id查詢所有的子類商品類型分類並在右邊顯示div追加展示;離開li或div時mouseleave事件改變回li原來的背景顏色同時隱藏展示div(離開li進入div並不觸發),當點擊對應的商品類型分類時,則按照該商品類型進行全文檢索並跳轉到檢索結果頁面。值得註意的是為了增加系統效率,我們先去redis緩存中查找,如果redis中沒有則去數據庫查詢,然後放到redis中,使用類型id作為key,使用字符串”TYPE”作為field。
系統公告
為了對平臺的一些信息跟狀態進行通知,特意在首頁開辟一塊區域作為公告欄。同樣是在頁面加載的時候ajax異步獲取系統公告信息,同樣為了增加系統效率,我們先去redis緩存中查找,如果redis中沒有則去數據庫查詢,然後放到redis中,使用作為key,使用字符串作為field。
精品閑置、求購推薦
熱門推薦作為廣告,跟中間的輪播大廣告一樣是要花錢才能上的,在熱門推薦中有兩種推薦方式,普通推薦跟VIP推薦,如果兩個都上了熱門推薦但先展示的是VIP推薦而不是普通推薦,意思就是VIP推薦會排在普通推薦前面。同樣是在頁面加載的時候使用ajax異步請求後臺,首頁展示的時候要查詢所有按照是否VIP推薦進行查找,查出來的數據先把VIP推薦add到list集合中再add普通推薦最後再把list返回。當然,為了增加系統效率,我們同樣先去redis緩存中查找,如果redis中沒有則去數據庫查詢,然後放到redis中,使用flag(0求購/1閑置)作為key,使用字符串” RECOMMEND”作為field。數據返回後追加排序展示。
搜索跟商品展示
solr全文檢索
作為一個二手交易平臺,必須要有全文檢索功能,在首頁的搜索輸入框可以發起搜索功能,眾所周知,當數據量大時,like模糊查詢效率太低,為了增加系統效率我們搭建solr全文檢索服務器,在配置文件註入bean對象HttpSolrServer,使用httpSolrServer操作SolrInputDocument文檔對象對solr服務器進行添加索引、更新索引、刪除索引、檢索索引,檢索索引需要創建SolrQuery查詢對象,通過設置關鍵字、設置分頁、設置排序、設置高亮顯示。執行httpSolrServer.query()方法,傳入SolrQuery對象返回QueryResponse結果集,遍歷結果集中的SolrDocumentListg按照配置field時設置的類型進行轉換取值,放到自定義SolrResult實體類中做異步請求的結果返回給前端做展示。
當然在使用之前要對solr進行配置,目前數據中就只有測試數據所以數據采集就只能通過使用httpSolrServer進行添加,配置field對不同的字段要進行不同的處理,比如價格price,存儲、索引、不分詞;標題title存儲、索引、分詞。為了使solr對中文的分詞效果更加友好,我們對solr進行配置第三方中文分詞器IKAnalyzer(添加對應jar、配置IKAnalyzer.cfg.xml)。按下搜索鍵後或單擊對應的商品類型後跳轉到搜索結果展示頁面,按照關鍵分頁展示並且字高亮顯示關鍵字,分頁結果還可以按照瀏覽量、價格進排序。
商品展示
在校園二手交易平臺中,登錄或未登錄都可以訪問index首頁跟showSell閑置商品展示頁面。當我們點擊熱門推薦中的商品或solr檢索結果頁面中的商品後跳轉URL到商品展示頁面並傳參數id過去,展示頁面通過攜帶id請求後臺獲取閑置商品的信息跟發布用戶的註冊信息以及發布用戶的認證信息,成功獲取後做結果集的返回,ajax直接調用回調函數直接操作DOM追加響應回來的數據,實現局部刷新。
同時,根據當前商品的商品類型去查詢熱門推薦表中的同種商品類型的商品,如果有則按照上面4.1.3.4 精品閑置、求購推薦的規則進行排序展示。
用戶管理
用戶登錄成功後默認跳轉到用戶管理頁面,用戶管理共有一下幾個功能:
基本信息
用戶可以查看自己的註冊用戶名、手機號碼、綁定郵箱,查看是否身份認證,如果沒有進行身份認證則進行4.1.6.2 校園身份認證功能,如果已經認證過了則彈框顯示認證信息,包括頭像。可以對手機號碼、綁定郵箱進行修改,前提是要保持唯一性。
校園身份認證功能
進行校園身份認證時本校園二手交易平臺的一大特色。我通過HttpClients模擬登陸教務系統,獲取學生信息,使用jsoup俗稱“大殺器”進行解析響應回來的html 匹配個人信息a標簽地址並做攜帶參數頁Referer進行第二次請求,使用jsoup來解析響應回來的htm匹配所有學生信息獲取我們想要的學生信息。在存儲過程中要進行唯一性認證,一個賬號只能認證一次,一個學生教務教務系統賬號只能綁定一個平臺賬號。目前頭像的上傳我是這樣做的,先把圖片下載的用戶電腦本地作為臨時文件,再調用FtpUtil.upload()方法讀取文件上傳到我們nginx圖片服務器,成功上傳後刪除用戶電腦中的臨時文件。(因為上傳需要傳入一個InputStream但是在寫代碼過程中發現從響應回來的HttpResponse獲取到的數據轉為InputStream時文件出現損失導致上傳後圖片無法正常打開的情況)。而一個重要的技術點就是驗證碼的問題,在編寫代碼時發現想使用Tesseract-OCR開源工具,然而,實現起來沒那麽簡單,所以我的做法是把教務系統的驗證碼直接writeTo到用戶的HttpServletResponse獲取圖片驗證碼,直接響應回瀏覽器,讓用戶自己手動輸入再傳到後臺。
發布閑置
發布閑置功能主要是使用了百度富文本UEditor,百度前端團隊開發的框架,簡單、輕量,正確引入後再js代碼中使用UE.getEditor實例化編輯器並調用getEditor方法創建編輯器實例,在ueditor.config.js配置文件中配置一些屬性、比如那些按鈕功能顯示在工具欄中,通過修改圖片上傳路徑,修改成上傳到我們的nginx圖片服務器上。UEditor內置有很多編輯功能跟圖片,足夠我們使用。
一個商品類型的二級聯動功能下拉框選擇商品商品,輸入表單信息跟商品描述信息、上傳好圖片後請求後臺發布閑置商品,攜帶的表單參數中商品描述describe_是html代碼,保存到數據庫中的類型是text。商品圖片photos保存的則是多張圖片圖片與圖片的路徑中間用“,”隔開,所以我們要從商品描述describe_的html代碼中匹配所有商品描述中的img標簽,獲取圖片路徑並保存到photos屬性中,多張圖時用,隔開並且過濾掉表情圖 img.baidu.com,如果用戶沒有上傳圖片,默認添加平臺默認的輪播圖片。設置瀏覽量0,設置商品狀態0(-1審核失敗/0審核中/1正常/審核失敗),獲取當前時間設為發布時間。發布成功後返回結果集前端頁面進行提示“發布成功,等待管理員審核”,管理員審核通過後即可在solr中檢索。
發布求購
發布求購跟4.1.6.3 發布閑置流程一樣,不同的是求購不需要有圖片輪播,但UEditor商品描述中依然要可以圖片,後臺代碼也沒有了去匹配img標簽,獲取圖片路徑,因為求購表沒有photos。後面的流程就跟發布閑置一樣了。
我的閑置
在這個功能中,可以查看、修改、下架我的閑置商品。在我的閑置中需要調用服務層子系統中的getSellByPage.do(用到mybatis的一個分頁插件pagehelper),像這種共有的、常用的查詢功能在後臺子系統要用到,所以把它提到服務層中去,使用封裝好的HttpClientUtil工具類調用,解析返回來的結果響應回前端頁面。查看功能是攜帶商品id請求後臺獲取商品的詳情信息並做彈窗顯示。修改功能則是對已經發布了的商品進行修改(商品類型不能修改),修改後需要管理員重新審核。值得註意的是逆向工程生成的mybatis的update語句是updateByPrimaryKey,但因為商品描述describe_的類型為text,所有必須要用updateByPrimaryKeyWithBLOBs才能更新。商品的下架則是修改了商品的狀態並不是真正的刪除數據,下架成功好同步更新solr,在大數據火的一塌糊塗的今天,數據是很重要的,一般來說是不會真正刪除數據。
我的求購
我的求購功能跟 我的閑置幾乎是一模一樣,業務流程也是相差甚微。
修改綁定郵箱
在本平臺中郵箱有消息推送的功能,比如管理員對用戶的發布審核後會發生一條郵箱進行結果的通知。在用戶管理頁面我們可以進行修改綁定郵箱操作。點擊修改按鈕,layer彈窗中引入bindingEamil.jsp頁面,攜帶新郵箱請求後臺直接存數據庫即可。
後臺子系統
後臺系統使用的是easyUI前端框架做前端頁面。首頁使用easyUI-tabs選項卡,頁面簡潔大方。
管理員登錄
相對於用戶登錄來說,管理員登錄就比較的簡單了,只是簡單的使用用戶名密碼去數據庫匹配,成功則跳轉後臺管理首頁。
用戶管理
用戶管理包括查看用戶信息、凍結用戶賬號、解除用戶賬號凍結狀態。使用easyUI的table網絡表格datagrid。配合使用mybatis的pagehelper分頁插件輕松快捷的實習分頁、排序功能。
點擊查看用戶信息後攜帶用戶id查詢用戶註冊信息,如果已經認證,獲取用戶認證證信息後做響應返回前端做layer彈框展示。凍結用戶賬號則是修改用戶信息中的狀態,修改成功後清除redis中該用戶的信息。做到實時狀態更新。解凍同樣也是修改狀態,但是不用對redis進行操作。
閑置管理
閑置管理同樣使用easyUI的table網絡表格datagrid。配合使用mybatis的pagehelper分頁插件實現分頁、排序。功能包括查看商品信息、加入普通推薦、加入VIP推薦、批準發布、駁回發布。查看功能需要查詢商品表跟用戶表以及用戶認證表,將所有關聯數據同時做返回layer彈框展示。批準、駁回則是修改商品的狀態、加入熱門推薦表就是將該商品加入到推薦中,如果已經是該類型的推薦則提示已經是該類型的推薦,否者加入成功。以上所有操作成功後都要清楚對應的redis,同時,批準發布成功後將該商品加入solr全文檢索服務器中。
求購管理
求購管理的業務流程跟 閑置管理差不多,相差無幾。
熱門推薦管理
熱門推薦是對熱門推薦表的管理,主要功能有查看跟刪除。查看就是根據id返回對應的信息前端彈框顯示,老套路了。刪除則將推薦信息刪除掉同時更新redis緩存即可。
廣告管理
廣告管理目前就只有中間大廣告輪播圖,可以每天對該廣告進行替換更新。主要功能有查看、修改、增加、刪除。全都是老套路,無需做太多的介紹了。有一點要註意的是添加時上傳的圖片也是上傳到我們的nginx圖片服務器上。同時,每個功能操作成功後都要對redis進行對應的更新。
服務層子系統
服務層是為了方便以後對平臺進行擴展,將一些公用的、常用的操作提到服務層,雖然它也單獨部署成了一個項目單他並沒有前端頁面。
主要的接口有根據閑置商品id獲取商品信息、分頁查詢閑置商品、根據求購id獲取商品信息、分頁查詢求購、查詢所有父類類型、根據父類id查詢所有子類、根據id查詢類型、根據id獲取發布者信息、根據發布者id獲取發布者認證信息、根據廣告位置,獲取廣告、獲取系統公告。
設計總結
經過了這幾個月的時間,從設計數據表到設計前端頁面最後到後臺代碼的開發,一整個流程下來雖然辛苦但自己也收獲很大,一邊工作一邊寫,很感激自己能堅持下來,感謝學校老師的指導!。現在項目基本完成,平臺功能基本能滿足學校的二手交易需求,平臺采用SSM框架開發,數據庫使用MySQL,整個項目進行分布式架構,降低了平臺的耦合度,對某個功能修改或增加新功能,都不會對其它功能模塊產生影響,將傳統部分功能拆分出來,形成各個獨立的子系統。各子系統之間都是以服務的形式提供API接口給其他模塊調用。平臺主要實現以下功能:
前臺:solr搜索、瀏覽、登錄註冊、個人中心、發布閑置/求購、學生身份認證等。
後臺:用戶管理、閑置管理、求購管理、熱門推薦管理、廣告管理等。
很遺憾,由於時間精力有限,雖然已經發現了諸多bug但未來得及進行修復,聊天功能也因為個人技術的限制開發到一半胎死腹中,最終還是沒能完成。前端的表單校驗也只是做了部分,平臺缺乏足夠的表單校驗,由於自己並不是專業的前端工程師,頁面並沒有做出自適應,也不夠美觀,瀏覽器頁面一縮放布局就亂掉。更沒有實現國際化,雖然也有做了部分參數抽取出來成配置文件,但頁面的文字顯示並沒有國際化。後臺部分,真的是能力、精力的限制,系統的健壯性也並沒有得到很好的保證,有些表單的非空、數據的判斷、後臺java異常的捕獲都沒有做,部分邏輯實現起來現在是沒有問題,但作為電商、門戶網站,當訪問量多時,多線程、高並發的時候,這種情況自己考慮的也並不是很完善。
基於SSM框架賀州學院校園二手交易平臺設計與實現