<input id="ohw05"></input>
  • <table id="ohw05"><menu id="ohw05"></menu></table>
  • <var id="ohw05"></var>
  • <code id="ohw05"><cite id="ohw05"></cite></code>
    <label id="ohw05"></label>
    <var id="ohw05"></var>
  • Loading

    前后端項目結構規范性記錄

    2021年9月15號更新

    【強制】前后端交互的 API,需要明確協議、域名、路徑、請求方法、請求內容、狀態碼、響應體。
    說明:
    1) 協議:生產環境必須使用 HTTPS。
    2) 路徑:每一個 API 需對應一個路徑,表示 API 具體的請求地址:
    a) 代表一種資源,只能為名詞,推薦使用復數,不能為動詞,請求方法已經表達動作意義。
    b) URL 路徑不能使用大寫,單詞如果需要分隔,統一使用下劃線。
    c) 路徑禁止攜帶表示請求內容類型的后綴,比如".json",".xml",通過 accept 頭表達即可。
    3) 請求方法:對具體操作的定義,常見的請求方法如下:
    a) GET:從服務器取出資源。
    b) POST:在服務器新建一個資源。
    c) PUT:在服務器更新資源。
    d) DELETE:從服務器刪除資源。
    4) 請求內容:URL 帶的參數必須無敏感信息或符合安全要求;body 里帶參數時必須設置 Content-Type。
    5) 響應體:響應體 body 可放置多種數據類型,由 Content-Type 頭來確定
    
    
    【強制】服務端發生錯誤時,返回給前端的響應信息必須包含 HTTP 狀態碼,errorCode、
    errorMessage、用戶提示信息四個部分。
    說明:四個部分的涉眾對象分別是瀏覽器、前端開發、錯誤排查人員、用戶。其中輸出給用戶的提示信息
    要求:簡短清晰、提示友好,引導用戶進行下一步操作或解釋錯誤原因,提示信息可以包括錯誤原因、上
    下文環境、推薦操作等。 errorCode:參考附表 3。errorMessage:簡要描述后端出錯原因,便于錯誤排
    查人員快速定位問題,注意不要包含敏感數據信息。
    正例:常見的 HTTP 狀態碼如下
    1) 200 OK: 表明該請求被成功地完成,所請求的資源發送到客戶端。
    2) 401 Unauthorized: 請求要求身份驗證,常見對于需要登錄而用戶未登錄的情況。
    3) 403 Forbidden:服務器拒絕請求,常見于機密信息或復制其它登錄用戶鏈接訪問服務器的情況。
    4) 404 Not Found: 服務器無法取得所請求的網頁,請求資源不存在。
    5) 500 Internal Server Error: 服務器內部錯誤
    
    
    【強制】對于需要使用超大整數的場景,服務端一律使用 String 字符串類型返回,禁止使用Long 類型。
    說明:Java 服務端如果直接返回 Long 整型數據給前端,JS 會自動轉換為 Number 類型(注:此類型為雙
    精度浮點數,表示原理與取值范圍等同于 Java 中的 Double)。Long 類型能表示的最大值是 2 的 63 次方
    -1,在取值范圍之內,超過 2 的 53 次方 (9007199254740992)的數值轉化為 JS 的 Number 時,有些數
    值會有精度損失。擴展說明,在 Long 取值范圍內,任何 2 的指數次整數都是絕對不會存在精度損失的,所
    以說精度損失是一個概率問題。若浮點數尾數位與指數位空間不限,則可以精確表示任何整數,但很不幸,
    雙精度浮點數的尾數位只有 52 位。
    反例:通常在訂單號或交易號大于等于 16 位,大概率會出現前后端單據不一致的情況,比如,"orderId": 
    362909601374617692,前端拿到的值卻是: 362909601374617660
    
    【推薦】不要在視圖模板中加入任何復雜的邏輯。
    說明:根據 MVC 理論,視圖的職責是展示,不要搶模型和控制器的活。
    【推薦】任何數據結構的構造或初始化,都應指定大小,避免數據結構無限增長吃光內存。
    【推薦】及時清理不再使用的代碼段或配置信息。
    說明:對于垃圾代碼或過時配置,堅決清理干凈,避免程序過度臃腫,代碼冗余。
    正例:對于暫時被注釋掉,后續可能恢復使用的代碼片斷,在注釋代碼上方,統一規定使用三個斜杠(///)
    來說明注釋掉代碼的理由。如:
     public static void hello() {
     /// 業務方通知活動暫停
     // Business business = new Business();
     // business.active();
     System.out.println("it's finished");
    }
    

    專有名詞解釋

    1. POJO(Plain Ordinary Java Object): 在本規約中,POJO 專指只有 setter/getter/toString 的
      簡單類,包括 DO/DTO/BO/VO 等。
    2. DO(Data Object):阿里巴巴專指數據庫表一一對應的 POJO 類。此對象與數據庫表結構一
      一對應,通過 DAO 層向上傳輸數據源對象。
    3. DTO(Data Transfer Object):數據傳輸對象,Service 或 Manager 向外傳輸的對象。
    4. BO(Business Object):業務對象,可以由 Service 層輸出的封裝業務邏輯的對象。
    5. Query:數據查詢對象,各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝,禁止使用
      Map 類來傳輸。
    6. VO(View Object):顯示層對象,通常是 Web 向模板渲染引擎層傳輸的對象。
    7. AO(Application Object): 阿里巴巴專指 Application Object,即在 Service 層上,極為貼近
      業務的復用代碼。
    8. CAS(Compare And Swap):解決多線程并行情況下使用鎖造成性能損耗的一種機制,這是
      硬件實現的原子操作。CAS 操作包含三個操作數:內存位置、預期原值和新值。如果內存位
      置的值與預期原值相匹配,那么處理器會自動將該位置值更新為新值。否則,處理器不做任何
      操作。
    9. GAV(GroupId、ArtifactId、Version): Maven 坐標,是用來唯一標識 jar 包。
    10. OOP(Object Oriented Programming): 本文泛指類、對象的編程處理方式。
    11. AQS(AbstractQueuedSynchronizer): 利用先進先出隊列實現的底層同步工具類,它是很多上
      層同步實現類的基礎,比如:ReentrantLock、CountDownLatch、Semaphore 等,它們通
      過繼承 AQS 實現其模版方法,然后將 AQS 子類作為同步組件的內部類,通常命名為 Sync。
    12. ORM(Object Relation Mapping): 對象關系映射,對象領域模型與底層數據之間的轉換,本
      文泛指 iBATIS, mybatis 等框架。
    13. NPE(java.lang.NullPointerException): 空指針異常。
    14. OOM(Out Of Memory): 源于 java.lang.OutOfMemoryError,當 JVM 沒有足夠的內存
      來為對象分配空間并且垃圾回收器也無法回收空間時,系統出現的嚴重狀況。
    15. 一方庫: 本工程內部子項目模塊依賴的庫(jar 包)。
    16. 二方庫: 公司內部發布到中央倉庫,可供公司內部其它應用依賴的庫(jar 包)。
    17. 三方庫: 公司之外的開源庫(jar 包)

    前言

    以前對這塊并沒有去具體了解,就是簡單的了解了一些小demo的開發流程。這次對這塊寫個記錄。


    后端

    分享一篇微信上的文章:《優秀的項目代碼是怎樣分層的》,這是來自B站一個Up主codesheep的文章。
    還有一篇文章:《Java命名規范》https://mp.weixin.qq.com/s/fY9crroOviqmstTZZIM5Ew
    接下里其實見得最多的就是阿里的這張圖以及阿里的解釋
    image

    圖片解釋

    ? 開放 API 層:可直接封裝 Service 接口暴露成 RPC 接口;通過 Web 封裝成 http 接口;網關控制層等。
    ? 終端顯示層:各個端的模板渲染并執行顯示的層。當前主要是 velocity 渲染,JS 渲染,JSP 渲染,移
    動端展示等。
    ? Web 層:主要是對訪問控制進行轉發,各類基本參數校驗,或者不復用的業務簡單處理等。
    ? Service 層:相對具體的業務邏輯服務層。
    ? Manager 層:通用業務處理層,它有如下特征:
    1) 對第三方平臺封裝的層,預處理返回結果及轉化異常信息,適配上層接口。
    2) 對 Service 層通用能力的下沉,如緩存方案、中間件通用處理。
    3) 與 DAO 層交互,對多個 DAO 的組合復用。
    ? DAO 層:數據訪問層,與底層 MySQL、Oracle、Hbase、OB 等進行數據交互。
    ? 第三方服務:包括其它部門 RPC 服務接口,基礎平臺,其它公司的 HTTP 接口,如淘寶開放平臺、支
    付寶付款服務、高德地圖服務等。
    ? 外部數據接口:外部(應用)數據存儲服務提供的接口,多見于數據遷移場景中。

    分層領域模型規約
    ? DO(Data Object):此對象與數據庫表結構一一對應,通過 DAO 層向上傳輸數據源對象。
    ? DTO(Data Transfer Object):數據傳輸對象,Service 或 Manager 向外傳輸的對象。
    ? BO(Business Object):業務對象,可以由 Service 層輸出的封裝業務邏輯的對象。
    ? Query:數據查詢對象,各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝,禁止使用 Map 類
    來傳輸。
    ? VO(View Object):顯示層對象,通常是 Web 向模板渲染引擎層傳輸的對象。

    image
    盡量對整個Maven工程結構進行分層拆分,增加工程的可擴展性,實現高內聚低耦合的開發要求。
    例子:圖中將工程拆分為一個父工程和三個子工程:
    ?CancerCenter:父工程,只有POM的約束,無具體業務代碼。
    ?CancerCenter_Common:通用工程,最下層依賴,包含utils,model,exception等整個項目的公共模塊,提供整個項目的基礎支撐。
    ?CancerCenter_Service:業務工程,向下依賴于Common,向上被Web依賴,包含service和mapper,是整個項目的核心業務。
    ?CancerCenter_Web:Web工程,向下依賴于Service,對外提供接口,包含接口、配置等Web項目獨有的模塊。


    前端

    image

    1.資源路徑編譯規則
    默認情況下,vue-loader 使用 css-loader 和 Vue 模版編譯器自動處理樣式和模版文件。在編譯過程中,所有的資源路徑例如 、background: url(...) 和 @import 會作為模塊依賴。
    路徑的編譯規則如下:
    如果路徑是絕對路徑,會原樣保留;
    如果路徑以 . 開頭,將會被看作相對的模塊依賴,并按照你的本地文件系統上的目錄結構進行解析;
    如果路徑以 @ 開頭,也會被看作模塊依賴。如果你的 webpack 配置中給 @ 配置了 alias,這就很有用了。所有 vue-cli 創建的項目都默認配置了將 @ 指向 /src;

    2.build目錄和config目錄
    build 目錄下存放的是 webpack 的配置文件;
    config 目錄下存放的是與項目構建相關的常用的配置選項、變量;
    通常情況下,除非要配置 webpack 的 loader 或者 插件,否則,你應該優先嘗試更改 config 目錄下的文件;

    ?

    3.src目錄
    根據項目結構的核心思想,src的目錄結構將以業務功能劃分。
    注意事項:
    I . 項目的業務代碼應該從 src/app/ 目錄開始;
    II . src/common/ 的子目錄中,在深度上的層級結構應該是盡量扁平的,不應該有很深的層級結構;如果 src/common/ 中的目錄樹 與 src/app/ 中的目錄樹在深度上有十分相似的層級結構,則就表示你應該重新考慮 src/common/ 中的資源是否是真的需要被共享的資源,被共享的資源的目錄層級結構應該是盡可能扁平的;對于不必共享的資源,應該放在 src/app/ 下相應的目錄結構中;
    III . src文件或文件夾的組成分為3種。直接在src目錄下的vue文件是工程內直接于業務相關頁面文件;components文件夾下是組件文件;其他文件夾是一些活動和主業務耦合性不大的文件。

    4.static目錄
    static目錄可以添加任何資源,如:圖片、代碼 等等。不過工程內圖片大多存放七牛,static/project.js存放公共函數

    微信文章:https://mp.weixin.qq.com/s/mNWc2tJWZlxJkKQh-kNpVg;可以參考一下,做個簡單的前端認識。
    下圖來自于該篇文章。
    image


    最后

    平時沒事可以看看《阿里開發手冊》,有助于對Java項目的開發流程的認識以及對規范的認識,可以有個良好的開發習慣。

    posted @ 2021-08-30 10:51  余月七  閱讀(584)  評論(0編輯  收藏  舉報
    国产美女a做受大片观看