1 前后端聯(lián)系
這個(gè)十分基礎(chǔ)吧，前端是提交的表單，在action里指定訪問的控制器域名。如下所示，在form標(biāo)簽指定了，userAdd的動(dòng)作，提交方式為post。
<form action="/userAdd" method="post">
之后，在后臺(tái)的控制層里，因?yàn)镾pring Boot的一個(gè)好處就是通過注解就可以進(jìn)行匹配，找到用戶登錄的代碼塊，使用@RequestMapping進(jìn)行標(biāo)記既可。
@ResponseBody
@RequestMapping("/userAdd")
2 獲取前端參數(shù)的方式
2.1 HttpServletRequest方法
很古老的方法，簡單來說就是通過調(diào)用request的getParameter方法來獲取參數(shù)。不建議使用。如圖：
2.2 參數(shù)對應(yīng)法
若傳入的數(shù)據(jù)量很小，就幾個(gè)基礎(chǔ)參數(shù)。可以在這里直接指定變量來接受既可，比如登錄的時(shí)候，前端就提交了兩個(gè)String變量的登錄賬戶和登錄密碼，后臺(tái)接受如下：
2.3 javabean接受法
這是后臺(tái)很常用的接受方式，因?yàn)榇蠖鄶?shù)系統(tǒng)后臺(tái)是根據(jù)數(shù)據(jù)庫表來建立了對應(yīng)的實(shí)體類型（也就是常見的entity或POJO）,而前端提交的數(shù)據(jù)幾乎都與這些實(shí)體類里的成員相關(guān)。所以在進(jìn)行數(shù)據(jù)操作時(shí)，很多后臺(tái)都是直接接受對應(yīng)的實(shí)體對象，然后在從接受的實(shí)體對象中取出對應(yīng)的值。如下：
但是，使用這種辦法必須值得提醒的是：前端頁面里的數(shù)據(jù)名字必須和實(shí)體成員的名字一樣?。?！否則無法對應(yīng)
比如：前端是name="userAcount"
登錄賬戶:<input type="text" name="userAcount" /></br>
實(shí)體中的成員名字必須是：userAcount
public class User {
private String userAcount;
2.4 混合型
當(dāng)然，這種情況也非常多。因?yàn)楹笈_(tái)操作會(huì)用到非常多的數(shù)據(jù)聯(lián)表操作，可能從前端接受的不止是一個(gè)實(shí)體對象中的成員，可能有其他實(shí)體對象中的成員，也可能還有其余的基礎(chǔ)成員。
這個(gè)時(shí)候，為了方便SQL數(shù)據(jù)的取出，就會(huì)創(chuàng)建一個(gè)新的POJO類來包含以上所有的實(shí)體成員，出現(xiàn)了一個(gè)大的POJO類里還有其余POJO類的情況。
比如以下，就是一個(gè)userAll類繼承了User，此外還有一個(gè)UserLove（用戶愛好）的POJO類
public class userAll extends User{`
private UserLove userLove;
這個(gè)時(shí)候，前端傳入的參數(shù)里既有User的成員信息，也有UserLove里的成員信息，我們不能在后臺(tái)直接使用userAll來接受。
public String addUser(userAll userAll)//錯(cuò)誤的方法
因?yàn)?，后臺(tái)接受不了UserLove里某個(gè)成員的信息，比如UserLove里有個(gè)loveSport成員，前端的傳入loveSport的值為football，后臺(tái)是接收不了這個(gè)loveSport的值。除非前端傳入整個(gè)UserLove類，但是前端一般不會(huì)傳入數(shù)據(jù)組的。
這個(gè)時(shí)候，還是老老實(shí)實(shí)的接受多個(gè)POJO類既可。如：
public String addUser(User user，UserLove userLove)
然后默默取出值就行。
