本節開始講認證相關的東西、注意事項，出現問題的對應的解決方案。
先寫用戶注冊的服務，注冊一些用戶信息進去。注冊也是我們安全體系的一部分
注冊
UserController里面的create方法
先修改實體類，加上username和password
因為我們已經在配置文件內配置了generate-ddl為true，啟動的時候jpa會自動把這兩個屬性加到數據庫里，這樣就不用我們自己手動去數據庫里加屬性。
設置主鍵的策略，這里設置的是根據當前數據庫的類型策略，例如當前是mysql數據庫，那么就會按照mysql數據庫的策略。自增的字段策略。
@GeneratedValue(strategy = GenerationType.IDENTITY)
strategy
美 ['strætədʒi]
英 ['strætədʒi]
- n.策略；戰略；策划；戰略部署
- 網絡策略模式；謀略；計謀
創建userInfo對象
復制user這個類，改個名字叫做userInfo。
這里把@Entity去掉。因為它不是實體，也就是不和數據庫內的表對應。UserInfo用來封裝我們服務的請求和響應。
保留@Data注解，這回幫我們生成get和set方法。
UserController里面凡事用到user的地方都改成UserInfo
那么為什么要這么改呢？這兩個對象從現在來看，屬性是一模一樣的，為什么要分成兩個呢？這就是編程里面比較常見的一個概念，關注點分離。
也叫做單一職責原則。任何一個類或者方法它應該只關注一個事，或者說只對一個事負責，只有當這個事變化的時候，我才需要改這個類或者這個方法，如果我們用User類來作為Controller的輸入或者輸出，那么User這個實際上就負責了兩件事。第一件事是跟我么的數據庫表做映射，這個對象反映出來我們數據庫有哪些字段，那個字段是主鍵等等這些信息，它是負責跟數據庫里的表做映射的。
而我們Controoler里面的方法 他的用參和出參實際上是服務的輸入和輸出。這個實際上是兩個概念。 如果我們在這兩個關注點上用同一個類。都用User的話，那么User負責的事情就會變多。這個類負責的事情變多就會導致，每一個事變化的時候我都要去改User,就會發生一些問題。
比如數據庫結構發生變化的時候，我要去改User，當創建用戶或者修改用戶的服務發生它的輸入和輸出發生變化的時候，我也需要去改User
。這個時候User這個類 它的職責就不清晰了。這不是一個好的編程概念。
舉個例子，例如用戶表里面加一個積分字段。 這個是一個很常見的需求。
如果我加了積分字段，在Controller里面還用User對象作為輸入或者輸出，就意味着我的注冊方法組要的字段里面也多了個積分字段。但是注冊的時候，基本沒有要求你填寫積分信息的吧？？？所以這就是我們為什么要建這個UserInfo對象的原因。這就是關注點分離。
大家在編程的時候也要注意這一點。它會讓你設計出良好的程序。
服務層Service
也就是我們常說的Service層。
在創建Service的實現類
controller層暴露app服務，app服務進來后交給service層，service層再去調用DAO也就是Repository做數據庫操作。這樣職責就完全區分開了
service層負責實現業務邏輯，Repository專門負責數據庫的操作，一般情況下Repository也不會有什么業務邏輯
聲明service內的方法。和controller內是對應的
在Service的Impl類里面都 實現這些方法。
把實現類聲明稱Spring的Service對象，也就是Spring的一個Bean
Controller內調用Service層的方法
寫Create方法。使用BeanUtils里面的方法，把傳進來的UserInfo對象的值都復制到User這個對象里面。
把user對象保存后的id，復制給info對象，再返回回去。這樣前天就能拿到你最終創建的這個用戶的id是多少。
這樣一個簡單的注冊就寫完了
運行測試
返回的狀態碼是200。返回的信息就是注冊的時候填寫的信息，同時還有數據庫最終生成的主鍵自增的id
日志里面打印出了insert語句
數據庫內的記錄
下面繼續寫認證的邏輯
先明確幾個概念，我們現在講的是認證，還不是登陸。
認證是驗證用戶的身份是否合法的這樣一個過程。認證這個事 不管 成沒成功，它都要往下走。它和登陸不一樣。登陸一旦有問題就斷掉了。比如說你登陸的時候用戶名和填錯了。那么我就直接拋異常了，不會再往下走了。認證的時候，如果你傳進來的用戶身份有問題，仍然要往下走，給下面的審核去記錄，記錄你這次的身份認證的結果是什么樣子的。最終這個請求是不是可以被通過，要由授權來決定。不是由認證來決定的。
明確好了這些概念。就可以寫代碼。
結束