網(wǎng)站建設(shè)框架使用的主流軟件架構(gòu)簡介，隨著網(wǎng)站建設(shè)軟件應用領(lǐng)域的擴展和軟件產(chǎn)品數(shù)量的激增，出現(xiàn)了適合各種需求的軟件架構(gòu)。隨著軟件工程技術(shù)的快速發(fā)展，軟件架構(gòu)也在不停地演進。推動這些架構(gòu)發(fā)展的力量是編程思想的進步及新技術(shù)和框架的產(chǎn)生。網(wǎng)站建設(shè)公司由于篇幅的原因，本節(jié)不能詳細介紹這些架構(gòu)及其發(fā)展過程，只能集中介紹幾個與深圳網(wǎng)站建設(shè)公司案例配套的演示項目相關(guān)的架構(gòu)，它們也是目前主流的軟件架構(gòu)，如分層架構(gòu)、REST架構(gòu)和微服務架構(gòu)等。
網(wǎng)站建設(shè)關(guān)于分層架構(gòu)
分層架構(gòu)(Layered Architecture）是目前為止最為常用的架構(gòu)，也是最符合軟件公司組織結(jié)構(gòu)的架構(gòu)。分層架構(gòu)的思想很簡單，把系統(tǒng)分解為若干個層(Layer)，每一層的邏輯代碼都具有高內(nèi)聚的特點，每層之間只能通過抽象的接口進行訪問，降低了層之間的耦合性。為了更合理地管理依賴關(guān)系，每一層只能訪問和它相鄰的低級別的層，并且只能向高一級的層提供服務，如圖3.5所示。
從圖3.5中可以看出，分層架構(gòu)簡單、易懂，大部分程序設(shè)計人員都可以理解。這種架構(gòu)的程序開發(fā)和測試都比較容易，在測試時每一層可以單獨進行，對下一層的依賴可以通過模擬獲取。網(wǎng)站建設(shè)使用分層架構(gòu)因為簡單、易用，被應用到大量的系統(tǒng)開發(fā)中。分層架構(gòu)在系統(tǒng)的模塊化和低耦合、高內(nèi)聚方面也起到了很好的作用。分層架構(gòu)是一種架構(gòu)風格，在其應用中約束了層之間的依賴和調(diào)用，每一層相當于上一層的服務器或基礎(chǔ)設(shè)施，而更深的層則完全隱身，并且不允許跨層調(diào)用，也不允許下層調(diào)用上層。下層對上層的調(diào)用只能通過中介模式。
在分層架構(gòu)風格中，層之間的隔離和約束為開發(fā)和測試提供了有力的保障，并有效地提高了軟件產(chǎn)品的質(zhì)量。層之間的調(diào)用通過抽象接口，避免了層之間的類型泄漏和相互依賴。通過層的隔離，保證了可修改性、可移植性和可重用性。
分層架構(gòu)風格在實際使用中可以選擇多種架構(gòu)模式。最常用的模式是4層架構(gòu)模式。這種模式把系統(tǒng)分解成4層，分別是UI層、應用程序?qū)?、業(yè)務邏輯層（或領(lǐng)域模型層)和數(shù)據(jù)訪問層。4個層的關(guān)注點各不相同。
UI層關(guān)注如何和用戶交互。應用程序?qū)雨P(guān)注如何提供系統(tǒng)的功能，它直接為UI層服務，為UI層獲取需要顯示的數(shù)據(jù)，以及解釋來自UI層的命令。業(yè)務邏輯層是系統(tǒng)的核心層，負責描述和解決特定領(lǐng)域的問題。數(shù)據(jù)訪問層把業(yè)務邏輯層中的對象狀態(tài)保存到數(shù)據(jù)庫中，并在需要時讀取出來。4層架構(gòu)模式如圖3.6所示。
4層架構(gòu)模式是分層架構(gòu)風格最簡單的應用，用十分簡單的方式實現(xiàn)了分層架構(gòu)風格的約束。但是由于這種架構(gòu)模式自身的弊端，并沒有被大規(guī)模應用。在該模式中，上層對下層的引用雖然以抽象的接口解耦，但是在描述返回數(shù)據(jù)值時十分困難。這時可以使用單獨的數(shù)據(jù)模型定義返回數(shù)據(jù)的類型。以UI層和應用程序?qū)訛槔尤霐?shù)據(jù)模型后的架構(gòu)如圖3.7所示。
加入數(shù)據(jù)模型以后，UI層和應用程序?qū)佣紩脭?shù)據(jù)模型，這樣就解決了返回數(shù)據(jù)類型的問題。當然，如果數(shù)據(jù)模型能夠貫穿整個系統(tǒng)分層，那么這個數(shù)據(jù)模型可以被所有層引用，從而成為所有層共享的數(shù)據(jù)模型。
數(shù)據(jù)模型的加入解決了部分問題，但同時也帶來了兩個問題。首先，數(shù)據(jù)模型的本意是定義各層之間需要傳遞的數(shù)據(jù)，在業(yè)務邏輯層用于描述問題和解決問題的是領(lǐng)域?qū)ο?。當從?shù)據(jù)訪問層獲取數(shù)據(jù)模型以后，還要提供一個數(shù)據(jù)模型到領(lǐng)域?qū)ο蟮碾p向轉(zhuǎn)換。如果直接把領(lǐng)域模型寫在數(shù)據(jù)模型中會帶來更大的麻煩，這—點在后面介紹領(lǐng)域模型時會詳細討論。
第二個問題來源于依賴。數(shù)據(jù)模型看似降低了依賴，甚至有的項目為了降低依賴，會把服務接口也定義在數(shù)據(jù)模型中，這其實是分層模式本身的問題。數(shù)據(jù)模型和接口都可以定義在單獨的包中，它們的定義都依賴于上層的需求。也就是說，下層的實現(xiàn)依賴于上層的定義，不管它們是否定義在單獨的包中，上層都會依賴于下層的實現(xiàn)而定義，這時就在上下兩層間形成了雙向依賴，這違背了依賴倒置原則(Dependence Inversion Principle)，即依賴于抽象而不依賴于實現(xiàn)，如圖3.8所示。
解決這個問題的方案是在層之間引入依賴注入。依賴注入是實現(xiàn)控制翻轉(zhuǎn)的一種形式，主要方法是通過依賴注入容器，實現(xiàn)層之間的解耦。注入依賴主要是為了解除上層對下層的引用依賴，下層保持對上層接口和數(shù)據(jù)類型的抽象依賴，而上層對下層的引用依賴被轉(zhuǎn)移到容器中。簡單地說，上層的調(diào)用接口仍然定義在上層，當上層需要使用下層實現(xiàn)的對象時，直接從容器中獲取即可，如圖3.9所示。
當引入依賴注入后，下層的服務接口及上層需要的數(shù)據(jù)類型都定義在上層，上層不引用下層，而下層引用上層。其實這時候上下層已經(jīng)互換了，原來的下層已經(jīng)變成了上層。在傳統(tǒng)的4層架構(gòu)中，數(shù)據(jù)訪問層作為實現(xiàn)的下層，在加入依賴注入后已經(jīng)變成了上層。
當數(shù)據(jù)訪問層變?yōu)樯蠈右院?，就可以為其他各層提供具體的服務，只是在各個層中需要定義服務的接口。而應用程序?qū)雍蜆I(yè)務邏輯層也不需要保持引用依賴。同時，數(shù)據(jù)訪問層提供了其他層的實現(xiàn)接口，也就成了其他層的基礎(chǔ)設(shè)施。UI層負責在初始化時把基礎(chǔ)設(shè)施層的實現(xiàn)對象注入容器中。引入依賴注入的4層架構(gòu)模式如圖3.10所示。
分層架構(gòu)是一個簡潔、易用的架構(gòu)模式，但是在很多項目中，由于開發(fā)者對分層架構(gòu)的錯誤理解，造成了各層之間錯誤的依賴關(guān)系。各層之間錯誤的依賴關(guān)系會使系統(tǒng)的穩(wěn)定性降低，只有使用依賴注入技術(shù)，才能真正解決分層架構(gòu)的依賴問題。好了，
深圳網(wǎng)站建設(shè)公司本文關(guān)于“
網(wǎng)站建設(shè)框架使用的主流軟件架構(gòu)簡介”的建站經(jīng)驗就分享到這里，謝謝關(guān)注，博納網(wǎng)絡編輯整理。
