我們可以關注一下定義中加粗部分的本質:框架是一種特殊的軟件;架構是比具體代碼高一個抽象層次的概念。
軟件框架會包含一些代碼——一系列完成計算的模塊,即構件;包含使用這個框架的規則和約束——構件之間的關係及交互機制、一系列可變點等。在框架的基礎上根據需要完成自定義的部分才能成爲最終的軟件產品。
軟件架構是可以用文檔和邏輯架構圖(像下面那樣)來表達的。它制定了領域問題的一套解決方案,關注大局而忽略細節,描述了計算組件及組件之間的交互,也可以說包含了一系列的決策.。
說白了,雖然這兩個詞語在日常使用中是近義詞,但在這裏討論的時候,一個(架構)仍然指軟件核心和主幹部分的東西,另一個(框架)卻更像是一套爲了方便別人套用的模具。
(1)爲了儘早驗證架構設計,或者處於支持產品線開發的目的,可以將關鍵的通用機制甚至整個架構以框架的方式進行實現;
(2)業界(及公司內部)可能存在大量可供重用的框架,這些框架或者已經實現了軟件架構所需的重要架構機制,或者爲未來系統的某個子系統提供了可擴展的半成品,所以最終的軟件架構可以藉助這些框架構造。
參見:架構和框架的區別
上圖爲一個掃碼點餐系統的邏輯架構圖,以此爲例,我們說說經典的三層架構給開發者帶來的便利。
首先,產品結構合理,模塊的的職責明確,具有高內聚性,模塊間耦合性較低。程序員能夠更有針對性的編程,更有序地分工合作。
其次,三層架構邏輯上分離了UI設計、領域關係、後臺實現的工作團隊裏各人能專注地做自己的事。例如我們的UI層就分別由兩個同學完成小程序端和後端的任務,他們只需要拿到設計稿和業務文檔就可以進行開發。
最後,層次間的聯繫由一些接口負責,關注這些接口內部的邏輯,可以清楚方便地對接和測試。
MVC架構我們都知道,當業務邏輯很複雜,model與controller之間的關係也很複雜的時候,我們就會需要統一管理controller(或者是MVP架構裏面的presenter)的變化。這就是所謂狀態管理的出衆,也是二者的相同之處。
不同之處在於解決方案:
它分爲四層:view視圖層、action層、dispatcher派發層、store倉庫層。
狀態發生變化時各層的響應是:view——>action——>dispatcher——>store返回——>dispatcher——>view。
vuex核心是:
狀態發生變化時各層的響應是:vueComnent——>(dispatch)Action——>(commit)——>Mutations——>(mutate)State——>(render)VueComponent
vuex多個組件調用一個狀態,將原來組件與組件之間的狀態傳遞改成組件與倉庫之間的傳遞,它適用於構建大型的項目。
如果不是大型項目,使用vuex會使代碼更加繁瑣。vue本身是針對組件編程的框架,層層組件之間的數據傳導相當麻煩。而獨立於組件出現的flux,天然的完成了數據傳導與presenter管理兩個麻煩問題。