統(tǒng)合約束條件
可以了，這個是設(shè)置里好的一個很都差不多的業(yè)務場景，當然了，不論什么樣的api操作，其中都真包含一些規(guī)則:
先添加收貨地址:入?yún)?
用戶id
收貨地址實體信息
約束:
用戶id肯定不能為空，且此用戶倒是是存在的
收貨地址的用處字段肯定不能為空
如果用戶還沒有收貨地址，當此收貨地址創(chuàng)建時設(shè)置成默認收貨地址—
徹底刪除收貨地址:入?yún)?
用戶id
收貨地址id
管理和約束:
用戶id沒法為空，且此用戶確實是修真者的存在的
收貨地址不能為空，且此收貨地址確實是存在地的
確認此收貨地址有無是用戶的收貨地址
可以確定此收貨地址是否是為默認收貨地址，如果是設(shè)置為收貨地址，那么又不能并且徹底刪除
你要改收貨地址:入?yún)?
用戶id
收貨地址id
強制力:
用戶id肯定不能為空，且此用戶的確是存在的
收貨地址肯定不能為空，且此收貨地址的確是存在的
確定此收貨地址是否是用戶的收貨地址
系統(tǒng)默認地址設(shè)置:入?yún)?
用戶id
收貨地址id
約束力:
用戶id又不能為空，且此用戶的確是未知的
收貨地址又不能為空，且此收貨地址倒是是存在地的
推測此收貨地址是否是用戶的收貨地址
收貨地址列表可以查詢:入?yún)?
用戶id
管理和約束:
用戶id肯定不能為空，且此用戶確實是是未知的
單個收到貨地址查詢:入?yún)?
用戶id
收貨地址id
加以約束:
用戶id不能不能為空，且此用戶確實是必然的
收貨地址又不能為空，且此收貨地址確實是未知的
確定此收貨地址是否是是用戶的收貨地址
加以約束判斷和技術(shù)選型
對此上述列個的約束條件和功能列表，我你選擇幾個比較是是的異常處理場景并且分析:再添加收貨地址，刪出收貨地址，獲取收貨地址列表 。
這樣應該是有哪些必要的知識儲備呢，讓我們看看收貨地址這個功能:
添加收貨地址中必須對用戶id和收貨地址實體信息就行校驗，那你對于非空的判斷，我們要如何接受工具的選擇呢？悠久的傳統(tǒng)的判斷::
上邊的例子，要是只可以確定uid為空不過，假如再去可以確定address這個實體中的某些必要的話屬性是否是為空，在字段很多的情況下，這所謂是災難性的 。
那我們應該怎么接受這些入?yún)⒌呐袛嗄?，給大家可以介紹兩個知識點:
Guava中的Preconditions類基于了很多入?yún)⒎椒ǖ呐袛?br />
jsr303的validation規(guī)范(目前基于比較好全的是hibernate實現(xiàn)程序的hibernate-validator)
如果不是使用了這兩種推薦一下技術(shù)，那么入?yún)⒌呐袛鄷兊酶雍唵蔚奶嗔?。幫我推薦大家多使用這些成熟的技術(shù)和jar工具包，他是可以下降很多不必要的工作量 。我們只必須把重心扔到業(yè)務邏輯上 。而應該不會畢竟這些入?yún)⒌呐袛鄵`更多的時間 。
要如何優(yōu)雅的設(shè)計什么java異常domain可以介紹
據(jù)項目場景來看，是需要兩個domain模型，一個是用戶實體，一個是地址實體.
Addressdomain如下:
Userdomaacross::
行啦,上邊是一個模型關(guān)系，用戶-收貨地址的關(guān)系是1-n的關(guān)系 。上邊的@Data是建議使用了一個就是lombok的工具，它自動導入了Setter和Getter等方法，用起來十分方便，感興趣的東西讀者這個可以自身清楚一下 。
dao能介紹
數(shù)據(jù)連接層，我們不使用了spring-data-jpa這個框架，它要求我們只不需要不能繼承框架需要提供的接口，因此通過約定對方法并且起名，就是可以能完成我們打算的數(shù)據(jù)庫操作 。
推薦閱讀
- 為什么花唄關(guān)了之后再開就用不了 花唄關(guān)閉后開通不了怎么解決
- 轉(zhuǎn)什么為什么成語四個字
- 年夜飯的寓意 為什么要吃年夜飯
- 年夜飯為什么叫尾牙 年夜飯什么時候吃
- excel表格為什么下邊沒有shift了 excel中下方的sheet不見了
- 為什么SSL證書的價格差異那么大 ssl證書有兩種
- 為什么右眼近視左眼不近視
- 為什么夏天下冰雹冬天不下
- 為什么白戶貸款都批不下來
- 星星為什么會眨眼睛答案