前兩天忙著寫開題報(bào)告，沒有來得及做項(xiàng)目，今天繼續(xù)研究一下這個(gè)項(xiàng)目。

　　上次研究到后端的DAO層，研究了一下后端和數(shù)據(jù)庫(kù)交互的過程，service層封裝了一些DAO層的函數(shù)，沒有什么太多的東西，今天研究一下controller層和前端的代碼。

　　首先，一個(gè)典型的controller層代碼是這樣的：

package...

import ...
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
public class LibraryController {
 @Autowired
 BookService bookService;

 @CrossOrigin
 @GetMapping("/api/books")
 public List<Book> list() throws Exception {
  return bookService.list();
 }

 ...
}

　　按照慣例，首先看一下各個(gè)注解：

　　@RestController：相當(dāng)于@ResponseBody+@Controller注解

　　@ResponseBody：@ResponseBody的作用其實(shí)是將java對(duì)象轉(zhuǎn)為json格式的數(shù)據(jù)。將controller的方法返回的對(duì)象通過適當(dāng)?shù)霓D(zhuǎn)換器轉(zhuǎn)換為指定的格式之后，寫入到response對(duì)象的body區(qū)。

　　@Controller：用于標(biāo)記在一個(gè)類上，使用它標(biāo)記的類就是一個(gè)SpringMVC Controller對(duì)象。分發(fā)處理器將會(huì)掃描使用了該注解的類的方法，并檢測(cè)該方法是否使用了@RequestMapping注解。@Controller只是定義了一個(gè)控制器類，而使用@RequestMapping注解的方法才是真正處理請(qǐng)求的處理器。

　　@Autowired：自動(dòng)裝配，和控制反轉(zhuǎn)什么的有關(guān)系，這個(gè)這里不展開了。

　　@CrossOrigin：跨域，這個(gè)問題大概就是說前后端不用一個(gè)服務(wù)器，瀏覽器對(duì)這種行為會(huì)出于安全考慮不允許跨域訪問，所以需要設(shè)置一下，具體細(xì)節(jié)比較瑣碎，這里不展開了。

　　@GetMapping：SpringMVC以前版本的@RequestMapping，到了新版本被下面新注釋替代，相當(dāng)于增加的選項(xiàng)：@GetMapping、@PostMapping、@PutMapping、@DeleteMapping、@PatchMapping，從命名約定我們可以看到每個(gè)注釋都是為了處理各自的傳入請(qǐng)求方法類型，即@GetMapping用于處理請(qǐng)求方法的GET類型，@PostMapping用于處理請(qǐng)求方法的POST類型等。如果我們想使用傳統(tǒng)的@RequestMapping注釋實(shí)現(xiàn)URL處理程序，那么它應(yīng)該是這樣的：@RequestMapping(value = "/get/{id}", method = RequestMethod.GET)，新方法可以簡(jiǎn)化為：@GetMapping("/get/{id}")。

　　后面的函數(shù)中還有一些其他的注解，一起看一下：

@CrossOrigin
 @PostMapping("/api/books")
 public Book addOrUpdate(@RequestBody Book book) throws Exception {
  bookService.addOrUpdate(book);
  return book;
 }

 @CrossOrigin
 @PostMapping("/api/delete")
 public void delete(@RequestBody Book book) throws Exception {
  bookService.deleteById(book.getId());
 }

 @CrossOrigin
 @GetMapping("/api/categories/{cid}/books")
 public List<Book> listByCategory(@PathVariable("cid") int cid) throws Exception {
  if (0 != cid) {
   return bookService.listByCategory(cid);
  } else {
   return list();
  }
 }

 @CrossOrigin
 @GetMapping("/api/search")
 public List<Book> searchResult(@RequestParam("keywords") String keywords) {
  // 關(guān)鍵詞為空時(shí)查詢出所有書籍
  if ("".equals(keywords)) {
   return bookService.list();
  } else {
   return bookService.Search(keywords);
  }
 }

　　@RequestBody：@RequestBody主要用來接收前端傳遞給后端的json字符串中的數(shù)據(jù)的(請(qǐng)求體中的數(shù)據(jù)的)；GET方式無請(qǐng)求體，所以使用@RequestBody接收數(shù)據(jù)時(shí)，前端不能使用GET方式提交數(shù)據(jù)，而是用POST方式進(jìn)行提交。

　　@PathVariable是spring3.0的一個(gè)新功能：接收請(qǐng)求路徑中占位符的值

　　@RequestParam：@RequestParam有三個(gè)配置參數(shù)：required表示是否必須，默認(rèn)為true，必須。defaultValue可設(shè)置請(qǐng)求參數(shù)的默認(rèn)值。value為接收url的參數(shù)名（相當(dāng)于key值。這個(gè)好像用法比較復(fù)雜，之后再仔細(xì)看一下。

Postman和chrome測(cè)試

　　首先我們登錄進(jìn)入系統(tǒng)，我這里前后端交互使用的8443端口，后續(xù)測(cè)試也在8443端口上進(jìn)行。

　　可以看到發(fā)送了一個(gè)請(qǐng)求報(bào)文，收到了一個(gè)回復(fù)報(bào)文，回復(fù)報(bào)文的內(nèi)容是一些json鍵值對(duì)，下面放了一個(gè)樣例：

{
  "id": 69,
  "category": {
   "id": 1,
   "name": "文學(xué)"
  },
  "cover": "https://i.loli.net/2019/04/10/5cad63931ce27.jpg",
  "title": "謀殺狄更斯",
  "author": "[美] 丹·西蒙斯 ",
  "date": "2019-4",
  "press": "上海文藝出版社",
  "abs": "“狄更斯的那場(chǎng)意外災(zāi)難發(fā)生在1865年6月9日，那列搭載他的成功、平靜、理智、手稿與情婦的火車一路飛馳，迎向鐵道上的裂隙，突然觸目驚心地墜落了?！?
 }

　　與Pojo中的book和category完全對(duì)應(yīng)，這里放一下代碼。

public class Book {
 @Id
 @GeneratedValue(strategy = GenerationType.IDENTITY)
 @Column(name = "id")
 int id;

 //把 category 對(duì)象的 id 屬性作為 cid 進(jìn)行了查詢
 @ManyToOne
 @JoinColumn(name="cid")
 private Category category;

 String cover;
 String title;
 String author;
 String date;
 String press;
 String abs;
 ...
}

public class Category {
 @Id
 @GeneratedValue(strategy = GenerationType.IDENTITY)
 @Column(name = "id")
 int id;

 String name;
 ...
}

　　前端的EditForm.vue中有這么一段代碼顯然是和這個(gè)相對(duì)應(yīng)的，這里我們先不去管這個(gè)：

　　我們接著測(cè)試一下其他方法：

　　構(gòu)造了一個(gè)post報(bào)文，返回200表示成功了，有趣的是雖然傳入了id，但是由于id是自增的，并沒有起作用，再使用get方法查詢一下。

　　下一個(gè)方法表示要?jiǎng)h除一本書，我們從代碼這個(gè)大概知道是拿到一個(gè)json對(duì)象，轉(zhuǎn)換成javabean的book，然后根據(jù)id把書刪除了，我們應(yīng)該傳入一個(gè)json對(duì)象的書，試一下：

　　成功了，但是有趣的是在chrome瀏覽器中，對(duì)于前端的行為不完全是這樣：

　　根據(jù)網(wǎng)上的教程，F(xiàn)12打開后，在Network下勾選Preserve log就可以監(jiān)控報(bào)文。

　　我們打開后刪除一本書。

　　雙擊點(diǎn)開后發(fā)現(xiàn)Request只傳遞了id，因?yàn)樵瓉砗瘮?shù)里只需要id，所以只傳id是完全沒毛病的，這個(gè)我在postman里面測(cè)過了，就不發(fā)上來了：

　　這個(gè)就是拿一個(gè)從url路徑里面拿一個(gè)參數(shù)，測(cè)試了一下不存在的分類號(hào)，不會(huì)報(bào)錯(cuò)，而是給一個(gè)空集合。

　　這個(gè)沒太看懂參數(shù)是怎么傳遞的，我們用Chrome看一下。

　　是通過在路徑后面加上“?keyword=關(guān)鍵詞”實(shí)現(xiàn)的。

　　去postman里面試一下，成功！

　　今天的探索到這里就結(jié)束了，后面再看一下前端代碼的邏輯，這個(gè)交互過程就比較清楚了。

到此這篇關(guān)于利用Postman和Chrome的開發(fā)者功能探究項(xiàng)目(畢業(yè)設(shè)計(jì)項(xiàng)目)的文章就介紹到這了,更多相關(guān)Postman和Chrome開發(fā)項(xiàng)目?jī)?nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論