石頭自清潔掃拖機器人G10S評測：多年黑科技集大成之作 懶人終極福音
科技圈經常能看到一個詞叫“縫合怪”，用來形容那些把好多功能或者外觀結合在一起的產品，通常這樣的詞是貶義詞，但如果真的是產品縫合的好、縫合的實用的話，那它就成了中性詞，今
談到應用程序的分層架構，很多人首先想到的是一個標準的模型，包括控制器（Controller）、服務層（Service）和數據訪問層（Mapper）三個主要部分。這聽起來似乎很直觀和簡單，但實際上，很多開發者在實施時并沒有明確區分這些層次的具體職責。例如，一些項目中，控制器層的代碼量反而超過了服務層，而服務層僅僅作為一個傳輸介質，這反映了開發過程中容易被忽視的問題。這種模糊的層級職責劃分，最終可能導致架構的混亂，使得代碼難以復用和維護
一個好的應用分層需要具備以下幾點：
方便后續代碼進行維護擴展；
分層的效果需要讓整個團隊都接受；
各層的職責邊界清晰。
圖片
阿里巴巴的編碼規范細化了應用程序架構的多個層次，旨在更清楚地界定各層的職責和作用。這些層次包括：
開放接口層：這一層負責將服務層的功能通過RPC接口或HTTP接口向外暴露，同時負責網關的安全和流量控制。
終端顯示層：負責在各種客戶端上渲染和顯示信息，使用不同的技術如Velocity、JavaScript、JSP進行頁面渲染和移動端展示。
Web層：處理訪問控制和轉發，進行基本的參數校驗和一些不需要復用的簡單業務處理。
服務層（Service層）：執行更具體的業務邏輯處理。
管理層（Manager層）：作為一個通用業務處理層，具備三個主要功能：封裝對第三方平臺的調用、下沉Service層的通用能力（如緩存和中間件處理）、以及與數據訪問層（DAO層）的交互，實現對數據訪問對象的復合使用。
數據訪問層（DAO層）：直接與數據庫（如MySQL、Oracle、Hbase）進行交互的層級。
首先需要說明的是，如果 RPC 框架選用 Thrift，可能會比其他的 RPC 框架多出一層，作用和 Controller 層類似：
圖片
阿里巴巴的架構分層規范中，最頂層由 Controller 和 TService 構成，主要職責是處理輕量級的業務邏輯、進行參數驗證和異常管理。
這一層設計的目的是保持足夠的靈活性，以便在需要時可以方便地更改或替換接口類型，因此這里的業務邏輯應盡可能簡化，有時甚至可以避免實現具體邏輯。
緊接著的是 Service 層，承擔著具體的業務邏輯處理。在這個層級，建議采取一種方法：讓每一個 Controller 操作都對應一個 Service 方法。
這樣做的好處是避免將業務邏輯的編排混入 Controller 層，從而在將來需要接入其他接口類型，如 Thrift 時，可以避免重復編排業務邏輯，減少代碼的重復和維護成本。這種方法強調了在不同層之間保持清晰的職責分離，以提高代碼的可維護性和可擴展性。
圖片
這樣大量的重復工作必定會導致開發效率下降，所以你要把業務編排邏輯都放進 Service 層中。
圖片
接下來是 Manager 層，這一層充當了可復用邏輯的核心角色。在這個層面上，Manager 可以是負責單一功能的服務，如緩存（Cache）、消息隊列（MQ）等；同時，它也能夠處理更復雜的任務，比如當需要同時調用多個 Manager 服務時，可以將它們組合成一個綜合性的 Manager，以處理更為復雜的業務邏輯，如在邏輯上進行類似于數據庫連表查詢的操作。
再來看 DAO 層，這是數據庫訪問層。主要負責“操作數據庫的某張表，映射到某個 Java 對象”，DAO 應該只允許自己的 Service 訪問。
在阿里巴巴的編碼規范中，分層領域模型的轉換是一個關鍵的設計考慮，以確保數據在不同層之間傳遞時的清晰性和準確性。以下是一些核心領域模型及其用途的概述：
DO（Data Object）：數據對象，直接與數據庫表結構對應，通過 DAO（數據訪問對象）層傳輸數據源對象。這確保了數據層與數據庫的直接映射，便于操作數據庫。
DTO（Data Transfer Object）：數據傳輸對象，用于服務層或管理層向外部傳輸的對象。DTO 主要用于跨層通訊，封裝了需要傳輸的數據，有助于減少一個方法調用所需要傳遞的參數數量，簡化遠程接口調用。
BO（Business Object）：業務對象，由服務層輸出，封裝了業務邏輯的對象。BO 體現了業務模型的概念，通常用于封裝具體的業務邏輯和業務狀態，反映了業務操作的結果。
AO（Application Object）：應用對象，位于 Web 層與服務層之間，是一個抽象的復用對象模型，非常貼近于展示層但復用度不高。AO 主要用于處理特定于應用的邏輯和狀態，作為不同服務層之間數據傳輸的中間層。
VO（View Object）：視圖對象，通常由 Web 層傳輸至模板渲染引擎層的對象。VO 主要用于展示層數據的封裝，專門為用戶界面定制，包含了用戶界面展示所需的數據。
Query：數據查詢對象，用于在各層之間傳遞查詢請求。它允許將查詢條件封裝為一個對象，使得方法調用更加清晰，同時避免了使用諸如 Map 這類無結構的數據類型來傳遞多個查詢條件，提高了代碼的可讀性和可維護性。
圖片
每一個層基本都有自己對應的領域模型，而有些人過于追求每一層都用自己的領域模型，這就導致在一次請求中，出現多次對象轉換。
一個折中的方案是：
允許 Service/Manager 可以操作數據領域模型。
Controller/TService 層的領域模型不允許傳入 DAO 層，這樣就不符合職責劃分了。
同理，不允許 DAO 層的數據傳入到 Controller/TService。
本文鏈接：http://www.www897cc.com/showinfo-26-80339-0.html你的項目應該如何正確分層？你會嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
下一篇： 消息隊列的七種經典應用場景
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號