首先建立一個springboot專案。

model層

model層也叫pojo層或者entity層，個人比較喜歡pojo層。
一般資料庫的一張表對應一個pojo層，並且表中所有欄位都在pojo層都一一對應。

然後要先建一個pojo的package，代表它是實體層。
再在該package下建立一個Goods的java檔案，建立的物件都是和表裡欄位一一對應，如下所示：

package pojo;

import lombok.*;

@Data
public class Goods {
    /*
    商品編號
     */
    private String GNo;

    /*
    商品名稱
     */
    private String GName;

    /*
    商品價格
     */
    private Double GPrice;
}

 

這裡的lombok的作用時為了簡化程式碼，因為對於private這樣的物件，想要呼叫它的時候，需要get和set兩個方法，而有了lombok之後就可以不用寫，直接用即可。
不過要新增依賴和註解@Data，lombok還有很多其他用法，之後可能會出一篇部落格。

通過maven下載依賴：

<dependency>
	<groupId>org.projectlombok</groupId>
	<artifactId>lombok</artifactId>
	<optional>true</optional>
</dependency>

 

這樣資料庫裡的欄位，我們就可以用物件來表示。

但是model不屬於springboot的三層框架。
主要說明是dao層、service層和controller層。
這些已經是屬於後端了。

對於一個專案，安全性是非常有必要的，所以springboot很好地體現了這一點。

比如：
想要訪問資料庫並且操作，只能通過dao層向資料庫傳送sql語句，將這些結果通過介面傳給service層。
想要處理資料，要先向dao層請求資料，對dao層傳過來的資料進行加工處理，將這些處理好的資料通過介面傳給controller層。
客戶想要查詢或修改資料時，要先向service層請求資料，收集service層傳過來的資料，將這些資料通過介面顯示給客戶，一般通過html等方法給客戶。
下面會一一說明。

Controller：

顧名思義，業務控制，就是控制業務層Service的，它的作用主要是架起了外界與業務層溝通的橋樑，移動端，前端在呼叫介面訪問相關業務時，都會通過Controller，由Controller去調相關的業務層程式碼並把資料返回給移動端和前端；

Service：

業務層，所有的內部的業務邏輯都會放在這裡處理，比如使用者的增刪改查，或者傳送個驗證碼或郵件，或者做一個抽獎活動等等等等，都會在Service中進行，當然，業務離肯定是離不開資料的支援，因此Dao層是必不可少的；

dao層

dao就不做解釋了，資料持久化層，就是和資料庫打交道的，而實現持久化層的框架又有很多，而常用的有兩種：JPA和MyBatis，JPA是SpringBoot官方的，前身就是著名的三大框架之一的Hibernate，好處是不用手寫SQL（當然它也支援手寫，如果必要的話），國外用的比較多，而MyBatis則在國內比較流行，原因是它的靈活性非常高，但是需要手寫SQL語句！關於它們誰更好的爭論從來沒有停止過，這裡不作討論，不過可以給出自己的一些建議：

專案複雜程度一般，追求穩定，迭代速率低的可以用JPA；
專案較複雜，需求變更頻繁，迭代速度快的可以用MyBatis；
我們瞭解了他們的作用後，可能有同學會問：為什麼必須要寫Service層，我直接用Controller層操作Dao層，省去Service層，豈不是更簡單？

我們知道Controller的作用，它是一個橋樑，或者說一箇中間者/服務者，打個比方，一個底層銷售想見馬雲，但馬雲豈是誰都可以見的？如見了面安全如何保障？所以就會通過一箇中間者或服務人員與銷售溝通，銷售通過中間者傳達自己的目的，中間者再經過整理後請示馬雲爸爸，最後把馬雲爸爸的反饋資訊轉給這個銷售，這樣銷售即達到了自己的目的，馬雲爸爸的安全也得到了保障，兩全其美！

因此，Controller層是不允許直接操作資料庫的！另外，Service對以後的分散式部署有極大的作用，它就像一個服務員，哪桌客人需要點菜了，就喊一聲服務員！對應的，外界需要完成什麼樣的業務，就通過Controller去呼叫不同的Service，需要記住的是，Controller只是一箇中間者或者轉發者，不應該在Controller裡暴露Service的業務邏輯，而應該直接轉發Service的業務處理結果！

一般的，一個Controller對應一個Service，一個Service對應一個Dao，一個Dao對應一個數據庫表，當然根據專案或業務複雜程度，一個Controller可以呼叫多個Service，而一個Service也可以呼叫多個Dao，但是Controller層不允許互調，Service層也不允許互調，意思就是AController不能直接呼叫BController，AService也不能直接去呼叫BService，遵循高內聚低耦合原則！

這樣，客戶可以通過請求的方式，將資料從前端傳給Controller層，然後一層一層傳下去，在一層一層地傳上來，實現了後端開發。

是不是發現和前端沒什麼關係？
是的，springboot還有一個優點就是實現了前後端分離，從而工作人員分配任務的時候更加具有條理性。而三層的架構可以讓程式設計師很快地知道bug出現在哪裡，哪一層，哪一檔案，很快的修改bug。

嗚呼，總而言之，springboot作為web開發的一個主流框架，正式因為這些優秀點讓它脫穎而出。