為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

項(xiàng)目整體架構(gòu)技術(shù)棧
Spring、SpringMVC、MyBatis、MySQL、JSP、OSS、定時(shí)器、微信相關(guān)接口

項(xiàng)目目錄結(jié)構(gòu)總結(jié)

只要在二個(gè)或二個(gè)以上地方用到的代碼必須抽取處理，抽取工具類。

校驗(yàn)方式和業(yè)務(wù)代碼混合在一塊不方便于代碼的維護(hù)。這里建議都使用hibernate-validator來做分組校驗(yàn)，可以提高校驗(yàn)的可讀性和擴(kuò)展性，或者使用aop做公共部分的業(yè)務(wù)做統(tǒng)一的校驗(yàn)處理。

這里的中文提示切記不要這樣寫，因?yàn)檫@里的校驗(yàn)提示不是在一個(gè)地方用到，提示在添加和修改會(huì)同時(shí)用到，所以切記重復(fù)使用二次或二次以上的代碼要進(jìn)行抽取，用常量類中統(tǒng)一處理。

統(tǒng)一提示頁面，該頁面用來處理所有form表單提交的同步請(qǐng)求（區(qū)別于一些ajax異步請(qǐng)求），對(duì)應(yīng)ajax異步請(qǐng)求建議采用前端封裝一個(gè)統(tǒng)一提示的模態(tài)框用于前端的一些參數(shù)校驗(yàn)和異步響應(yīng)的后臺(tái)提示。

controller 調(diào)用service 的insert接口，建議不要再封裝一個(gè)其他的BaseModel，然后再用BaseModel的返回值處理，這種寫法對(duì)應(yīng)經(jīng)常用這種方式的可以，但對(duì)于一些其他的陌生這種開發(fā)方式的人來說提影響開發(fā)效率的。這里建議，調(diào)用service返回的？？？待總結(jié)

切記controller中的請(qǐng)求路徑一定要有一定的規(guī)范，這樣代碼即美觀有方便維護(hù)，每個(gè)模塊要?jiǎng)澐置鞔_，也便于做權(quán)限管理。

最好都生成一個(gè)package-info.java 并在這個(gè)java類中填寫一定的模塊介紹，方便代碼的維護(hù)，這樣當(dāng)你10年后回來看自己的代碼也不會(huì)那么迷茫了。

首先用mybatis-generator 自動(dòng)生成代碼速度快，但都建議生成xml代碼后進(jìn)行一定的調(diào)整，調(diào)整可以如下：
1. 多使用xml代碼片段（表名，表列名，多條件查詢）
2. update一般都是根據(jù)主鍵id來局部更新的，所以寫一個(gè)update就可以了，用if判斷一下再去更新。
3. 生成的代碼中都是對(duì)參數(shù)做了jdbcType類型處理了，建議都去掉，可以提供代碼的擴(kuò)展信息（隨便添加字段就不用擔(dān)心類型寫錯(cuò)了）

前后臺(tái)交互封裝成對(duì)象的方式：
1. 前臺(tái)是通過ajax異步請(qǐng)求請(qǐng)求后臺(tái)路徑或在app接口開發(fā)的時(shí)候，建議可以采用如下正確的寫法2。

2. 封裝比較合適的相應(yīng)參數(shù)

不管是mapper接口中還是service接口中保存和更新需要設(shè)置返回值嗎？但你設(shè)置返回值的時(shí)候保存成功必然返回值為1，但保持失敗必定是拋出jdbc操作數(shù)據(jù)庫異常，所以我這里建議使用不設(shè)置返回值且不用返回值來處理業(yè)務(wù)邏輯，成功代碼執(zhí)行完成，失敗捕獲異常返回給前端。需要證實(shí)

在同一個(gè)service方法中涉及到二個(gè)或二個(gè)以上更改數(shù)據(jù)操作的方法中必須設(shè)置回滾事務(wù)操作，不然會(huì)造成數(shù)據(jù)的不一致。當(dāng)有一個(gè)select和一個(gè)insert的時(shí)候可以不做回滾處理，因?yàn)椴粫?huì)影響數(shù)據(jù)的一致性。

在頁面的分模塊管理也盡量常用統(tǒng)一的命名和和controller請(qǐng)求路徑的機(jī)制命名，方便代碼的定位和編寫代碼的效率。比如listView，可以在多個(gè)模塊中來回拷貝，改個(gè)標(biāo)題名可以用了。還有就是對(duì)應(yīng)一些如：頁面頂部或底部div盡量都抽取出來，做代碼的復(fù)用，這樣就不用再多個(gè)頁面中來回改了，改一個(gè)頁面就可用，減少bug數(shù)量，提高效率。

在每個(gè)頁面的公共頭部分加入公共代碼basePath這樣就能在多個(gè)頁面中取這個(gè)值用于不同頁面的請(qǐng)求url了。

定義統(tǒng)一異常處理，針對(duì)不同的異常來統(tǒng)一處理，這個(gè)時(shí)候在service就可以自定義異常類來統(tǒng)一處理異常，這個(gè)時(shí)候在service操作異常后就直接拋出自定義的異常就行，在controller也不要對(duì)異常進(jìn)行處理了。

盡量在數(shù)據(jù)庫中不要用int來存身份和角色相關(guān)的屬性，這樣沒有文檔誰都看不懂，使用varchar就行，就是多占點(diǎn)空間而已，但對(duì)于代碼的可讀性和可維護(hù)性提高不少，即使你數(shù)據(jù)庫中使用的時(shí)候int來存儲(chǔ)，切記在代碼中也要使用常量屬性來定義類型，并寫上注釋。

切記一切上傳功能（oss）都要抽取工具類，且抽取方式要合理，不要把一切代碼都寫在service中，這樣代碼可讀性不高。

在上傳oss功能中，當(dāng)上傳的時(shí)候（先上傳，然后再把上傳后的url插入到數(shù)據(jù)庫中），當(dāng)在插入數(shù)據(jù)庫的時(shí)候失敗切記一定要?jiǎng)h除之前上傳的圖片，不然后來的oss文件根本沒法維護(hù)。還有就是上面的那個(gè)問題，insert失敗后是直接拋出異常還是返回0，直接拋出異常下面的代碼就是永遠(yuǎn)都不會(huì)走的代碼就沒有任何意義了。

service 可以使用void 不用自己再封裝baseModel 了，然后一些業(yè)務(wù)異常就拋出自定義的異常，如果是操作過程中沒有拋出任何異常，就在controller直接業(yè)務(wù)操作成功。

對(duì)應(yīng)controller中的多個(gè)查詢因?yàn)椴粫?huì)涉及到事物一致性，所有就直接查詢實(shí)體存放到model中就行。

轉(zhuǎn)載于:https://my.oschina.net/qrmc/blog/1927292

總結(jié)

以上是生活随笔為你收集整理的规范-编码规范总结（微信分销系统）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。