乐优商城项目实战系列2
0.學習目標
- 使用資料搭建后臺系統
- 會使用nginx進行反向代理
- 實現商品分類查詢功能
- 掌握cors解決跨域
- 實現品牌查詢功能
1.搭建后臺管理前端
1.1.導入已有資源
后臺項目相對復雜,為了有利于教學,我們不再從0搭建項目,而是直接使用課前資料中給大家準備好的源碼:
我們解壓縮,放到工作目錄中:
然后在Intellij idea中導入新的工程:
選中我們的工程:
1.2.安裝依賴
你應該注意到,這里并沒有node_modules文件夾,方便給大家下發,已經把依賴都刪除了。不過package.json中依然定義了我們所需的一切依賴:
我們只需要打開終端,進入項目目錄,輸入:npm install命令,即可安裝這些依賴。
大概需要幾分鐘。
如果安裝過程出現以下問題:
建議刪除node_modules目錄,重新安裝。或者copy其他人的node_modules使用
1.3.運行一下看看
在package.json文件中有scripts啟動腳本配置,可以輸入命令:npm run dev或者npm start
發現默認的端口是9001。訪問:http://localhost:9001
會自動進行跳轉:
1.4.目錄結構
webpack:是一個現代 JavaScript 應用程序的靜態模塊打包器(module bundler)。并且提供了前端項目的熱部署插件。
1.5.調用關系
我們最主要理清index.html、main.js、App.vue之間的關系:
理一下:
- index.html:html模板文件。定義了空的div,其id為app。
- main.js:實例化vue對象,并且通過id選擇器綁定到index.html的div中,因此main.js的內容都將在index.html的div中顯示。main.js中使用了App組件,即App.vue,也就是說index.html中最終展現的是App.vue中的內容。index.html引用它之后,就擁有了vue的內容(包括組件、樣式等),所以,main.js也是webpack打包的入口。
- index.js:定義請求路徑和組件的映射關系。相當于之前的<vue-router>
- App.vue中也沒有內容,而是定義了vue-router的錨點:<router-view>,我們之前講過,vue-router路由后的組件將會在錨點展示。
- 最終結論:一切路由后的內容都將通過App.vue在index.html中顯示。
- 訪問流程:用戶在瀏覽器輸入路徑,例如:http://localhost:9001/#/item/brand --> index.js(/item/brand路徑對應pages/item/Brand.vue組件) --> 該組件顯示在App.vue的錨點位置 --> main.js使用了App.vue組件,并把該組件渲染在index.html文件中(id為“app”的div中)
2.Vuetify框架
2.1.為什么要學習UI框架
Vue雖然會幫我們進行視圖的渲染,但樣式還是由我們自己來完成。這顯然不是我們的強項,因此后端開發人員一般都喜歡使用一些現成的UI組件,拿來即用,常見的例如:
- BootStrap
- LayUI
- EasyUI
- ZUI
然而這些UI組件的基因天生與Vue不合,因為他們更多的是利用DOM操作,借助于jQuery實現,而不是MVVM的思想。
而目前與Vue吻合的UI框架也非常的多,國內比較知名的如:
- element-ui:餓了么出品
- i-view:某公司出品
然而我們都不用,我們今天推薦的是一款國外的框架:Vuetify
官方網站:https://vuetifyjs.com/zh-Hans/
2.2.為什么是Vuetify
有中國的為什么還要用外國的?原因如下:
- Vuetify幾乎不需要任何CSS代碼,而element-ui許多布局樣式需要我們來編寫
- Vuetify從底層構建起來的語義化組件。簡單易學,容易記住。
- Vuetify基于Material Design(谷歌推出的多平臺設計規范),更加美觀,動畫效果酷炫,且風格統一
這是官網的說明:
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Uedr7xD4-1642863683461)(assets/1530555978248.png)]
缺陷:
- 目前官網雖然有中文文檔,但因為翻譯問題,幾乎不太能看。
2.3.怎么用?
基于官方網站的文檔進行學習:
我們重點關注UI components即可,里面有大量的UI組件,我們要用的時候再查看,不用現在學習,先看下有什么:
以后用到什么組件,就來查詢即可。
2.4.項目頁面布局
接下來我們一起看下頁面布局。
Layout組件是我們的整個頁面的布局組件:
里面使用了Vuetify中的2個組件和一個布局元素:
-
v-navigation-drawer :導航抽屜,主要用于容納應用程序中的頁面的導航鏈接。
-
v-toolbar:工具欄通常是網站導航的主要途徑。可以與導航抽屜一起很好地工作,動態選擇是否打開導航抽屜,實現可伸縮的側邊欄。
-
v-content:并不是一個組件,而是標記頁面布局的元素。可以根據您指定的app組件的結構動態調整大小,使得您可以創建高度可定制的組件。
那么問題來了:v-content中的內容來自哪里?
- Layout映射的路徑是/
- 除了Login以外的所有組件,都是定義在Layout的children屬性,并且路徑都是/的下面
- 因此當路由到子組件時,會在Layout中定義的錨點中顯示。
- 并且Layout中的其它部分不會變化,這就實現了布局的共享。
3.使用域名訪問本地項目
3.1.統一環境
我們現在訪問頁面使用的是:http://localhost:9001
有沒有什么問題?
實際開發中,會有不同的環境:
- 開發環境:自己的電腦
- 測試環境:提供給測試人員使用的環境
- 預發布環境:數據是和生成環境的數據一致,運行最新的項目代碼進去測試
- 生產環境:項目最終發布上線的環境
如果不同環境使用不同的ip去訪問,可能會出現一些問題。為了保證所有環境的一致,我們會在各種環境下都使用域名來訪問。
我們將使用以下域名:
- 主域名是:www.leyou.com,leyou.com
- 管理系統域名:manage.leyou.com
- 網關域名:api.leyou.com
- …
但是最終,我們希望這些域名指向的還是我們本機的某個端口。
那么,當我們在瀏覽器輸入一個域名時,瀏覽器是如何找到對應服務的ip和端口的呢?
3.2.域名解析
一個域名一定會被解析為一個或多個ip。這一般會包含兩步:
-
本地域名解析
瀏覽器會首先在本機的hosts文件中查找域名映射的IP地址,如果查找到就返回IP ,沒找到則進行域名服務器解析,一般本地解析都會失敗,因為默認這個文件是空的。
- Windows下的hosts文件地址:C:/Windows/System32/drivers/etc/hosts
- Linux下的hosts文件所在路徑: /etc/hosts
樣式:
# My hosts 127.0.0.1 localhost -
域名服務器解析
本地解析失敗,才會進行域名服務器解析,域名服務器就是網絡中的一臺計算機,里面記錄了所有注冊備案的域名和ip映射關系,一般只要域名是正確的,并且備案通過,一定能找到。
3.3.解決域名解析問題
我們不可能去購買一個域名,因此我們可以偽造本地的hosts文件,實現對域名的解析。修改本地的host為:
127.0.0.1 api.leyou.com 127.0.0.1 manage.leyou.com這樣就實現了域名的關系映射了。
每次在C盤尋找hosts文件并修改是非常麻煩的,給大家推薦一個快捷修改host的工具,在課前資料中可以找到:
解壓,運行exe文件,效果:
我們添加了兩個映射關系(中間用空格隔開):
- 127.0.0.1 api.leyou.com :我們的網關Zuul
- 127.0.0.1 manage.leyou.com:我們的后臺系統地址
現在,ping一下域名試試是否暢通:
OK!
通過域名訪問:
原因:我們配置了項目訪問的路徑,雖然manage.leyou.com映射的ip也是127.0.0.1,但是webpack會驗證host是否符合配置。
在webpack.dev.conf.js中取消host驗證:disableHostCheck: true
重新執行npm run dev,刷新瀏覽器:
OK!
3.4.nginx解決端口問題
域名問題解決了,但是現在要訪問后臺頁面,還得自己加上端口:http://manage.taotao.com:9001。
這就不夠優雅了。我們希望的是直接域名訪問:http://manage.taotao.com。這種情況下端口默認是80,如何才能把請求轉移到9001端口呢?
這里就要用到反向代理工具:Nginx
3.4.1.什么是Nginx
nginx可以作為web服務器,但更多的時候,我們把它作為網關,因為它具備網關必備的功能:
- 反向代理
- 負載均衡
- 動態路由
- 請求過濾
3.4.2.nginx作為web服務器
Web服務器分2類:
- web應用服務器,如:
- tomcat
- resin
- jetty
- web服務器,如:
- Apache 服務器
- Nginx
- IIS
區分:web服務器不能解析jsp等頁面,只能處理js、css、html等靜態資源。
并發:web服務器的并發能力遠高于web應用服務器。
3.4.3.nginx作為反向代理
什么是反向代理?
- 代理:通過客戶機的配置,實現讓一臺服務器代理客戶機,客戶的所有請求都交給代理服務器處理。
- 反向代理:用一臺服務器,代理真實服務器,用戶訪問時,不再是訪問真實服務器,而是代理服務器。
nginx可以當做反向代理服務器來使用:
- 我們需要提前在nginx中配置好反向代理的規則,不同的請求,交給不同的真實服務器處理
- 當請求到達nginx,nginx會根據已經定義的規則進行請求的轉發,從而實現路由功能
利用反向代理,就可以解決我們前面所說的端口問題,如圖
3.4.4.安裝和使用
安裝
安裝非常簡單,把課前資料提供的nginx直接解壓即可,綠色免安裝,舒服!
我們在本地安裝一臺nginx:
解壓后,目錄結構:
反向代理配置
示例:
nginx中的每個server就是一個反向代理配置,可以有多個server
完整配置:
#user nobody; worker_processes 1;events {worker_connections 1024; }http {include mime.types;default_type application/octet-stream;sendfile on;keepalive_timeout 65;gzip on;server {listen 80;server_name manage.leyou.com;proxy_set_header X-Forwarded-Host $host;proxy_set_header X-Forwarded-Server $host;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;location / {proxy_pass http://127.0.0.1:9001;proxy_connect_timeout 600;proxy_read_timeout 600;}}server {listen 80;server_name api.leyou.com;proxy_set_header X-Forwarded-Host $host;proxy_set_header X-Forwarded-Server $host;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;location / {proxy_pass http://127.0.0.1:10010;proxy_connect_timeout 600;proxy_read_timeout 600;}} }使用
nginx可以通過命令行來啟動,操作命令:
- 啟動:start nginx.exe
- 停止:nginx.exe -s stop
- 重新加載:nginx.exe -s reload
啟動過程會閃爍一下,啟動成功后,任務管理器中會有兩個nginx進程:
3.5.測試
啟動nginx,然后用域名訪問后臺管理系統:
現在實現了域名訪問網站了,中間的流程是怎樣的呢?
瀏覽器準備發起請求,訪問http://mamage.leyou.com,但需要進行域名解析
優先進行本地域名解析,因為我們修改了hosts,所以解析成功,得到地址:127.0.0.1
請求被發往解析得到的ip,并且默認使用80端口:http://127.0.0.1:80
本機的nginx一直監聽80端口,因此捕獲這個請求
nginx中配置了反向代理規則,將manage.leyou.com代理到127.0.0.1:9001,因此請求被轉發
后臺系統的webpack server監聽的端口是9001,得到請求并處理,完成后將響應返回到nginx
nginx將得到的結果返回到瀏覽器
4.實現商品分類查詢
商城的核心自然是商品,而商品多了以后,肯定要進行分類,并且不同的商品會有不同的品牌信息,我們需要依次去完成:商品分類、品牌、商品的開發。
4.1.導入數據
首先導入課前資料提供的sql:
我們先看商品分類表:
CREATE TABLE `tb_category` (`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '類目id',`name` varchar(20) NOT NULL COMMENT '類目名稱',`parent_id` bigint(20) NOT NULL COMMENT '父類目id,頂級類目填0',`is_parent` tinyint(1) NOT NULL COMMENT '是否為父節點,0為否,1為是',`sort` int(4) NOT NULL COMMENT '排序指數,越小越靠前',PRIMARY KEY (`id`),KEY `key_parent_id` (`parent_id`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=1424 DEFAULT CHARSET=utf8 COMMENT='商品類目表,類目和商品(spu)是一對多關系,類目與品牌是多對多關系';因為商品分類會有層級關系,因此這里我們加入了parent_id字段,對本表中的其它分類進行自關聯。
4.2.實現功能
在瀏覽器頁面點擊“分類管理”菜單:
根據這個路由路徑到路由文件(src/route/index.js),可以定位到分類管理頁面:
由路由文件知,頁面是src/pages/item/Category.vue
商品分類使用了樹狀結構,而這種結構的組件vuetify并沒有為我們提供,這里自定義了一個樹狀組件。不要求實現或者查詢組件的實現,只要求可以參照文檔使用該組件即可:
4.2.1.url異步請求
點擊商品管理下的分類管理子菜單,在瀏覽器控制臺可以看到:
頁面中沒有,只是發起了一條請求:http://api.leyou.com/api/item/category/list?pid=0
大家可能會覺得很奇怪,我們明明是使用的相對路徑:/item/category/list,講道理發起的請求地址應該是:
http://manage.leyou.com/item/category/list
但實際卻是:
http://api.leyou.com/api/item/category/list?pid=0
這是因為,我們有一個全局的配置文件,對所有的請求路徑進行了約定:
路徑是http://api.leyou.com,并且默認加上了/api的前綴,這恰好與我們的網關設置匹配,我們只需要把地址改成網關的地址即可,因為我們使用了nginx反向代理,這里可以寫域名。
接下來,我們要做的事情就是編寫后臺接口,返回對應的數據即可。
4.2.2.實體類
在leyou-item-interface中添加category實體類:
內容:
@Table(name="tb_category") public class Category {@Id@GeneratedValue(strategy=GenerationType.IDENTITY)private Long id;private String name;private Long parentId;private Boolean isParent; // 注意isParent生成的getter和setter方法需要手動加上Isprivate Integer sort;// getter和setter略 }需要注意的是,這里要用到jpa的注解,因此我們在leyou-item-iterface中添加jpa依賴
<dependency><groupId>javax.persistence</groupId><artifactId>persistence-api</artifactId><version>1.0</version> </dependency>4.2.3.controller
編寫一個controller一般需要知道四個內容:
- 請求方式:決定我們用GetMapping還是PostMapping
- 請求路徑:決定映射路徑
- 請求參數:決定方法的參數
- 返回值結果:決定方法的返回值
在剛才頁面發起的請求中,我們就能得到絕大多數信息:
-
請求方式:Get,插敘肯定是get請求
-
請求路徑:/api/item/category/list。其中/api是網關前綴,/item是網關的路由映射,真實的路徑應該是/category/list
-
請求參數:pid=0,根據tree組件的說明,應該是父節點的id,第一次查詢為0,那就是查詢一級類目
-
返回結果:??
根據前面tree組件的用法我們知道,返回的應該是json數組:
[{ "id": 74,"name": "手機","parentId": 0,"isParent": true,"sort": 2},{ "id": 75,"name": "家用電器","parentId": 0,"isParent": true,"sort": 3} ]對應的java類型可以是List集合,里面的元素就是類目對象了。也就是List<Category>
添加Controller:
controller代碼:
@Controller @RequestMapping("category") public class CategoryController {@Autowiredprivate CategoryService categoryService;/*** 根據父id查詢子節點* @param pid* @return*/@GetMapping("list")public ResponseEntity<List<Category>> queryCategoriesByPid(@RequestParam("pid") Long pid) {if (pid == null || pid.longValue() < 0) {// 響應400,相當于ResponseEntity.status(HttpStatus.BAD_REQUEST).build();return ResponseEntity.badRequest().build();}List<Category> categories = this.categoryService.queryCategoriesByPid(pid);if (CollectionUtils.isEmpty(categories)) {// 響應404return ResponseEntity.notFound().build();}return ResponseEntity.ok(categories);} }4.2.4.service
一般service層我們會定義接口和實現類,不過這里我們就偷懶一下,直接寫實現類了:
@Service public class CategoryService {@Autowiredprivate CategoryMapper categoryMapper;/*** 根據parentId查詢子類目* @param pid* @return*/public List<Category> queryCategoriesByPid(Long pid) {Category record = new Category();record.setParentId(pid);return this.categoryMapper.select(record);} }4.2.5.mapper
我們使用通用mapper來簡化開發:
public interface CategoryMapper extends Mapper<Category> { }要注意,我們并沒有在mapper接口上聲明@Mapper注解,那么mybatis如何才能找到接口呢?
我們在啟動類上添加一個掃描包功能:
@SpringBootApplication @EnableDiscoveryClient @MapperScan("com.leyou.item.mapper") // mapper接口的包掃描 public class LeyouItemServiceApplication {public static void main(String[] args) {SpringApplication.run(LeyouItemServiceApplication.class, args);} }4.2.6.啟動并測試
我們不經過網關,直接訪問:http://localhost:8081/category/list
然后試試網關是否暢通:http://api.leyou.com/api/item/category/list
一切OK!
然后刷新后臺管理頁面查看:
發現報錯了!
瀏覽器直接訪問沒事,但是這里卻報錯,什么原因?
這其實是瀏覽器的同源策略造成的跨域問題。
5.跨域問題
跨域:瀏覽器對于javascript的同源策略的限制 。
以下情況都屬于跨域:
| 域名不同 | www.jd.com 與 www.taobao.com |
| 域名相同,端口不同 | www.jd.com:8080 與 www.jd.com:8081 |
| 二級域名不同 | item.jd.com 與 miaosha.jd.com |
如果域名和端口都相同,但是請求路徑不同,不屬于跨域,如:
www.jd.com/item
www.jd.com/goods
http和https也屬于跨域
而我們剛才是從manage.leyou.com去訪問api.leyou.com,這屬于二級域名不同,跨域了。
5.1.為什么有跨域問題?
跨域不一定都會有跨域問題。
因為跨域問題是瀏覽器對于ajax請求的一種安全限制:一個頁面發起的ajax請求,只能是與當前頁域名相同的路徑,這能有效的阻止跨站攻擊。
因此:跨域問題 是針對ajax的一種限制。
但是這卻給我們的開發帶來了不便,而且在實際生產環境中,肯定會有很多臺服務器之間交互,地址和端口都可能不同,怎么辦?
5.2.解決跨域問題的方案
目前比較常用的跨域解決方案有3種:
-
Jsonp
最早的解決方案,利用script標簽可以跨域的原理實現。
限制:
- 需要服務的支持
- 只能發起GET請求
-
nginx反向代理
思路是:利用nginx把跨域反向代理為不跨域,支持各種請求方式
缺點:需要在nginx進行額外配置,語義不清晰
-
CORS
規范化的跨域請求解決方案,安全可靠。
優勢:
- 在服務端進行控制是否允許跨域,可自定義規則
- 支持各種請求方式
缺點:
- 會產生額外的請求
我們這里會采用cors的跨域方案。
5.3.cors解決跨域
5.3.1.什么是cors
CORS是一個W3C標準,全稱是"跨域資源共享"(Cross-origin resource sharing)。
它允許瀏覽器向跨源服務器,發出XMLHttpRequest請求,從而克服了AJAX只能同源使用的限制。
CORS需要瀏覽器和服務器同時支持。目前,所有瀏覽器都支持該功能,IE瀏覽器不能低于IE10。
-
瀏覽器端:
目前,所有瀏覽器都支持該功能(IE10以下不行)。整個CORS通信過程,都是瀏覽器自動完成,不需要用戶參與。
-
服務端:
CORS通信與AJAX沒有任何差別,因此你不需要改變以前的業務邏輯。只不過,瀏覽器會在請求中攜帶一些頭信息,我們需要以此判斷是否允許其跨域,然后在響應頭中加入一些信息即可。這一般通過過濾器完成即可。
5.3.2.原理有點復雜
瀏覽器會將ajax請求分為兩類,其處理方案略有差異:簡單請求、特殊請求。
5.3.2.1.簡單請求
只要同時滿足以下兩大條件,就屬于簡單請求。:
(1) 請求方法是以下三種方法之一:
- HEAD
- GET
- POST
(2)HTTP的頭信息不超出以下幾種字段:
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type:只限于三個值application/x-www-form-urlencoded、multipart/form-data、text/plain
當瀏覽器發現發起的ajax請求是簡單請求時,會在請求頭中攜帶一個字段:Origin.
Origin中會指出當前請求屬于哪個域(協議+域名+端口)。服務會根據這個值決定是否允許其跨域。
如果服務器允許跨域,需要在返回的響應頭中攜帶下面信息:
Access-Control-Allow-Origin: http://manage.leyou.com Access-Control-Allow-Credentials: true Content-Type: text/html; charset=utf-8- Access-Control-Allow-Origin:可接受的域,是一個具體域名或者*(代表任意域名)
- Access-Control-Allow-Credentials:是否允許攜帶cookie,默認情況下,cors不會攜帶cookie,除非這個值是true
有關cookie:
要想操作cookie,需要滿足3個條件:
- 服務的響應頭中需要攜帶Access-Control-Allow-Credentials并且為true。
- 瀏覽器發起ajax需要指定withCredentials 為true
- 響應頭中的Access-Control-Allow-Origin一定不能為*,必須是指定的域名
5.3.2.2.特殊請求
不符合簡單請求的條件,會被瀏覽器判定為特殊請求,,例如請求方式為PUT。
預檢請求
特殊請求會在正式通信之前,增加一次HTTP查詢請求,稱為"預檢"請求(preflight)。
瀏覽器先詢問服務器,當前網頁所在的域名是否在服務器的許可名單之中,以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答復,瀏覽器才會發出正式的XMLHttpRequest請求,否則就報錯。
一個“預檢”請求的樣板:
OPTIONS /cors HTTP/1.1 Origin: http://manage.leyou.com Access-Control-Request-Method: PUT Access-Control-Request-Headers: X-Custom-Header Host: api.leyou.com Accept-Language: en-US Connection: keep-alive User-Agent: Mozilla/5.0...與簡單請求相比,除了Origin以外,多了兩個頭:
- Access-Control-Request-Method:接下來會用到的請求方式,比如PUT
- Access-Control-Request-Headers:會額外用到的頭信息
預檢請求的響應
服務的收到預檢請求,如果許可跨域,會發出響應:
HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 01:15:39 GMT Server: Apache/2.0.61 (Unix) Access-Control-Allow-Origin: http://manage.leyou.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: GET, POST, PUT Access-Control-Allow-Headers: X-Custom-Header Access-Control-Max-Age: 1728000 Content-Type: text/html; charset=utf-8 Content-Encoding: gzip Content-Length: 0 Keep-Alive: timeout=2, max=100 Connection: Keep-Alive Content-Type: text/plain除了Access-Control-Allow-Origin和Access-Control-Allow-Credentials以外,這里又額外多出3個頭:
- Access-Control-Allow-Methods:允許訪問的方式
- Access-Control-Allow-Headers:允許攜帶的頭
- Access-Control-Max-Age:本次許可的有效時長,單位是秒,過期之前的ajax請求就無需再次進行預檢了
如果瀏覽器得到上述響應,則認定為可以跨域,后續就跟簡單請求的處理是一樣的了。
5.3.3.實現非常簡單
雖然原理比較復雜,但是前面說過:
- 瀏覽器端都有瀏覽器自動完成,我們無需操心
- 服務端可以通過攔截器統一實現,不必每次都去進行跨域判定的編寫。
事實上,SpringMVC已經幫我們寫好了CORS的跨域過濾器:CorsFilter ,內部已經實現了剛才所講的判定邏輯,我們直接用就好了。
在leyou-gateway中編寫一個配置類,并且注冊CorsFilter:
import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.web.cors.CorsConfiguration; import org.springframework.web.cors.UrlBasedCorsConfigurationSource; import org.springframework.web.filter.CorsFilter;@Configuration public class LeyouCorsConfig {@Beanpublic CorsFilter corsFilter() {//1.添加CORS配置信息CorsConfiguration config = new CorsConfiguration();//1) 允許的域,不要寫*,否則cookie就無法使用了config.addAllowedOrigin("http://manage.leyou.com");//2) 是否發送Cookie信息config.setAllowCredentials(true);//3) 允許的請求方式config.addAllowedMethod("OPTIONS");config.addAllowedMethod("HEAD");config.addAllowedMethod("GET");config.addAllowedMethod("PUT");config.addAllowedMethod("POST");config.addAllowedMethod("DELETE");config.addAllowedMethod("PATCH");// 4)允許的頭信息config.addAllowedHeader("*");//2.添加映射路徑,我們攔截一切請求UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();configSource.registerCorsConfiguration("/**", config);//3.返回新的CorsFilter.return new CorsFilter(configSource);} }結構:
重啟測試,訪問正常:
分類的增刪改功能暫時就不做了,頁面已經預留好了事件接口,有興趣的同學可以完成一下。
6.品牌的查詢
商品分類完成以后,自然輪到了品牌功能了。
先看看我們要實現的效果:
點擊“品牌管理”菜單:
路由路徑:/item/brand
根據路由文件知,對應的頁面是:src/pages/item/Brand.vue
頁面會發送如下請求:
6.1.后臺提供查詢接口
前臺頁面已經準備好,接下來就是后臺提供數據接口了。
6.1.1.數據庫表
CREATE TABLE `tb_brand` (`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '品牌id',`name` varchar(50) NOT NULL COMMENT '品牌名稱',`image` varchar(200) DEFAULT '' COMMENT '品牌圖片地址',`letter` char(1) DEFAULT '' COMMENT '品牌的首字母',PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=325400 DEFAULT CHARSET=utf8 COMMENT='品牌表,一個品牌下有多個商品(spu),一對多關系';簡單的四個字段,不多解釋。
這里需要注意的是,品牌和商品分類之間是多對多關系。因此我們有一張中間表,來維護兩者間關系:
CREATE TABLE `tb_category_brand` (`category_id` bigint(20) NOT NULL COMMENT '商品類目id',`brand_id` bigint(20) NOT NULL COMMENT '品牌id',PRIMARY KEY (`category_id`,`brand_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品分類和品牌的中間表,兩者是多對多關系';但是,你可能會發現,這張表中并沒有設置外鍵約束,似乎與數據庫的設計范式不符。為什么這么做?
- 外鍵會嚴重影響數據庫讀寫的效率
- 數據刪除時會比較麻煩
在電商行業,性能是非常重要的。我們寧可在代碼中通過邏輯來維護表關系,也不設置外鍵。
6.1.2.實體類
@Table(name = "tb_brand") public class Brand {@Id@GeneratedValue(strategy = GenerationType.IDENTITY)private Long id;private String name;// 品牌名稱private String image;// 品牌圖片private Character letter;// getter setter 略 }6.1.3.mapper
通用mapper來簡化開發:
public interface BrandMapper extends Mapper<Brand> { }6.1.4.controller
編寫controller先思考四個問題,參照前端頁面的控制臺
- 請求方式:查詢,肯定是Get
- 請求路徑:分頁查詢,/brand/page
- 請求參數:根據我們剛才編寫的頁面,有分頁功能,有排序功能,有搜索過濾功能,因此至少要有5個參數:
- page:當前頁,int
- rows:每頁大小,int
- sortBy:排序字段,String
- desc:是否為降序,boolean
- key:搜索關鍵詞,String
- 響應結果:分頁結果一般至少需要兩個數據
- total:總條數
- items:當前頁數據
- totalPage:有些還需要總頁數
這里我們封裝一個類,來表示分頁結果:
public class PageResult<T> {private Long total;// 總條數private Integer totalPage;// 總頁數private List<T> items;// 當前頁數據public PageResult() {}public PageResult(Long total, List<T> items) {this.total = total;this.items = items;}public PageResult(Long total, Long totalPage, List<T> items) {this.total = total;this.totalPage = totalPage;this.items = items;}public Long getTotal() {return total;}public void setTotal(Long total) {this.total = total;}public List<T> getItems() {return items;}public void setItems(List<T> items) {this.items = items;}public Long getTotalPage() {return totalPage;}public void setTotalPage(Long totalPage) {this.totalPage = totalPage;} }另外,這個PageResult以后可能在其它項目中也有需求,因此我們將其抽取到leyou-common中,提高復用性:
不要忘記在leyou-item-service工程的pom.xml中引入leyou-common的依賴:
<dependency><groupId>com.leyou.common</groupId><artifactId>leyou-common</artifactId><version>1.0.0-SNAPSHOT</version> </dependency>接下來,我們編寫Controller
@RestController @RequestMapping("brand") public class BrandController {@Autowiredprivate BrandService brandService;/*** 根據查詢條件分頁并排序查詢品牌信息* @param key* @param page* @param rows* @param sortBy* @param desc* @return*/@GetMapping("page")public ResponseEntity<PageResult<Brand>> queryBrandsByPage(@RequestParam(value = "key", required = false)String key,@RequestParam(value = "page", defaultValue = "1")Integer page,@RequestParam(value = "rows", defaultValue = "5")Integer rows,@RequestParam(value = "sortBy", required = false)String sortBy,@RequestParam(value = "desc", required = false)Boolean desc){PageResult<Brand> result = this.brandService.queryBrandsByPage(key, page, rows, sortBy, desc);if (CollectionUtils.isEmpty(result.getItems())){return ResponseEntity.notFound().build();}return ResponseEntity.ok(result);} }6.1.5.Service
@Service public class BrandService {@Autowiredprivate BrandMapper brandMapper;/*** 根據查詢條件分頁并排序查詢品牌信息** @param key* @param page* @param rows* @param sortBy* @param desc* @return*/public PageResult<Brand> queryBrandsByPage(String key, Integer page, Integer rows, String sortBy, Boolean desc) {// 初始化example對象Example example = new Example(Brand.class);Example.Criteria criteria = example.createCriteria();// 根據name模糊查詢,或者根據首字母查詢if (StringUtils.isNotBlank(key)) {criteria.andLike("name", "%" + key + "%").orEqualTo("letter", key);}// 添加分頁條件PageHelper.startPage(page, rows);// 添加排序條件if (StringUtils.isNotBlank(sortBy)) {example.setOrderByClause(sortBy + " " + (desc ? "desc" : "asc"));}List<Brand> brands = this.brandMapper.selectByExample(example);// 包裝成pageInfoPageInfo<Brand> pageInfo = new PageInfo<>(brands);// 包裝成分頁結果集返回return new PageResult<>(pageInfo.getTotal(), pageInfo.getList());} }6.1.6.測試
通過瀏覽器訪問試試:http://api.leyou.com/api/item/brand/page
接下來,去頁面請求數據并渲染
6.2.異步查詢工具axios
異步查詢數據,自然是通過ajax查詢,大家首先想起的肯定是jQuery。但jQuery與MVVM的思想不吻合,而且ajax只是jQuery的一小部分。因此不可能為了發起ajax請求而去引用這么大的一個庫。
6.2.1.axios入門
Vue官方推薦的ajax請求框架叫做:axios,看下demo:
axios的Get請求語法:
axios.get("/item/category/list?pid=0") // 請求路徑和請求參數拼接.then(function(resp){// 成功回調函數}).catch(function(){// 失敗回調函數}) // 參數較多時,可以通過params來傳遞參數 axios.get("/item/category/list", {params:{pid:0}}).then(function(resp){})// 成功時的回調.catch(function(error){})// 失敗時的回調axios的POST請求語法:
比如新增一個用戶
axios.post("/user",{name:"Jack",age:21}).then(function(resp){}).catch(function(error){})注意,POST請求傳參,不需要像GET請求那樣定義一個對象,在對象的params參數中傳參。post()方法的第二個參數對象,就是將來要傳遞的參數
PUT和DELETE請求與POST請求類似
6.2.2.axios的全局配置
而在我們的項目中,已經引入了axios,并且進行了簡單的封裝,在src下的http.js中:
http.js中對axios進行了一些默認配置:
import Vue from 'vue' import axios from 'axios' import config from './config' // config中定義的基礎路徑是:http://api.leyou.com/api axios.defaults.baseURL = config.api; // 設置axios的基礎請求路徑 axios.defaults.timeout = 2000; // 設置axios的請求時間Vue.prototype.$http = axios;// 將axios賦值給Vue原型的$http屬性,這樣所有vue實例都可使用該對象-
http.js中導入了config的配置,還記得嗎?
-
http.js對axios進行了全局配置:baseURL=config.api,即http://api.leyou.com/api。因此以后所有用axios發起的請求,都會以這個地址作為前綴。
-
通過Vue.property.$http = axios,將axios賦值給了 Vue原型中的$http。這樣以后所有的Vue實例都可以訪問到$http,也就是訪問到了axios了。
6.2.3.項目中使用
我們在組件Brand.vue的getDataFromServer方法,通過$http發起get請求,測試查詢品牌的接口,看是否能獲取到數據:
網絡監視:
resp到底都有那些數據,查看控制臺結果:
可以看到,在請求成功的返回結果response中,有一個data屬性,里面就是真正的響應數據。
響應結果中與我們設計的一致,包含3個內容:
- total:總條數,目前是165
- items:當前頁數據
- totalPage:總頁數,我們沒有返回
6.3.完成分頁和過濾
6.3.1.分頁
點擊分頁,會發起請求,通過瀏覽器工具查看,會發現pagination對象的屬性一直在變化:
我們可以利用Vue的監視功能:watch,當pagination發生改變時,會調用我們的回調函數,我們在回調函數中進行數據的查詢!
具體實現:
成功實現分頁功能:
6.3.2.過濾
過濾字段對應的是search屬性,我們只要監視這個屬性即可:
查看網絡請求:
頁面結果:
總結
以上是生活随笔為你收集整理的乐优商城项目实战系列2的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: GoF设计模式——适配器模式(C++实现
- 下一篇: 手工画设计模式的类图