基於SSM框架賀州學院校園二手交易平臺設計與實現

前言

　　這個是我當時的畢業論文，分享出來，給同窗們參考。

緒論

　　隨着中國新四大發明的誕生，網購成了千千萬萬網友們購物的新方式，新的購物方式促進商業的發展，但隨着人們生活水平的提升，許多新購置的物品用了沒多少天，甚至沒多少次就開始嫌棄、就開始再也不使用，成爲了閒置物品，大量的閒置物品已然爆發式增加。

　　在網購人羣中，學生網購已是很是常見，隨着購物的便捷，學生們四年下來手裏頭有着太多的閒置的廢舊物，一到大四畢業季，學生離校時都會丟棄一些學習資料和生活用具，這些閒置的廢舊物形成校園垃圾增加，給環境保潔員工做帶來極大的壓力，更是形成了資源浪費。做爲本屆的畢業生我深有體會。

　　而如今網上主流的二手交易平臺「閒魚」、「轉轉」，更多的是面向同城交易、國內外交易，缺少一個面向學生羣體的二手交易平臺，而學生消費羣體，一到每一年的畢業季大量的閒置物品沒法及時處理，而想要購置二手物品的大1、大二等同校的同窗因爲缺少途徑，並不知道那個學長學姐有哪些閒置的物品。若是學校有一個本身的校園二手交易平臺，而已發佈者身份真實明確，就是咱們學校的學生，那咱們的學弟學妹就能夠直接在咱們學校本身的校園二手交易平臺上購置同校友發佈的閒置物品，方便又安心，而對於咱們畢業生來講，直接把閒置物品放在咱們本身學校的二手交易平臺，直接在校園內就能交易，方便快捷、省心省事。

　　對於每個即將離校的學生來講，不管以前是如何的嫌棄學校的各類很差，抱怨飯堂的有多很差吃，到了要離開的時候，多少都是有點捨不得。而經過二手交易平臺，把回憶留給校園，閒置物品留給學弟學妹，還能換一張離去的車票，一舉多得！

　　

摘要

　　本平臺採用分佈式系統架構，擬定有如下幾個模塊：後臺子系統：管理員按權限職能不一樣，能夠分別對平臺進行不一樣程度的管理、維護等。門戶子系統：solr搜索、瀏覽、登陸註冊、我的中心、發佈閒置/求購、學生身份認證等。服務層子系統：爲了方便之後對平臺進行擴展，將一些公用的、經常使用的操做提到服務層。同時，對項目中所用到的知識點進行簡單介紹。

　　平臺的特點及創新點

　　一、SSM框架開發，數據庫使用MySQL，整個項目進行分佈式架構，下降了平臺的耦合度，對某個功能修改或增長新功能，都不會對其它功能模塊產生影響，將傳統部分功能拆分出來，造成各個獨立的子系統。各子系統之間都是以服務的形式提供API接口給其餘模塊調用

　　二、使用solr搜索引擎、搭建nginx圖片服務器、單機版redis緩存數據庫，大大提升效率，以應付高訪問，高併發（美中不足的是沒有搭建集羣作高可用）

　　三、使用學校教務系統帳號進行賀州學院學生身份認證（經過HttpClient模擬登錄），發佈者身份信息真實、平臺由學生（能夠跟計算機協會合做，由他們進行維護）維護，平臺安全可靠

　　四、註冊時使用手機短信註冊，每一個手機號只能註冊一次，忘記密碼時，能夠選擇手機找回或郵箱帳號（需綁定）

 

平臺架構圖

 

 

數據字典

    （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異常的捕獲都沒有作，部分邏輯實現起來如今是沒有問題，但做爲電商、門戶網站，當訪問量多時，多線程、高併發的時候，這種狀況本身考慮的也並非很完善。