軟件架構與框架

區別與聯繫

定義

  • 軟件框架是面向領域(如ERP、計算領域等)的、可複用的「半成品」軟件,它實現了該領域的共性部分,並提供了一些定義良好的可變點以保證靈活性和可擴展性。也就是說軟件框架是領域分析結果的軟件化,是領域內最終應用的模板。
  • 軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細緻地描述組件之間的通訊。

參見:軟件框架和軟件架構的區別?

說說區別加深理解

我們可以關注一下定義中加粗部分的本質:框架是一種特殊的軟件;架構是比具體代碼高一個抽象層次的概念。

軟件框架會包含一些代碼——一系列完成計算的模塊,即構件;包含使用這個框架的規則和約束——構件之間的關係及交互機制、一系列可變點等。在框架的基礎上根據需要完成自定義的部分才能成爲最終的軟件產品。
軟件架構是可以用文檔和邏輯架構圖(像下面那樣)來表達的。它制定了領域問題的一套解決方案,關注大局而忽略細節,描述了計算組件及組件之間的交互,也可以說包含了一系列的決策.。

說白了,雖然這兩個詞語在日常使用中是近義詞,但在這裏討論的時候,一個(架構)仍然指軟件核心和主幹部分的東西,另一個(框架)卻更像是一套爲了方便別人套用的模具。

站在高處看聯繫

(1)爲了儘早驗證架構設計,或者處於支持產品線開發的目的,可以將關鍵的通用機制甚至整個架構以框架的方式進行實現;
(2)業界(及公司內部)可能存在大量可供重用的框架,這些框架或者已經實現了軟件架構所需的重要架構機制,或者爲未來系統的某個子系統提供了可擴展的半成品,所以最終的軟件架構可以藉助這些框架構造。

參見:架構和框架的區別

三層架構模型圖例

這裏寫圖片描述
上圖爲一個掃碼點餐系統的邏輯架構圖,以此爲例,我們說說經典的三層架構給開發者帶來的便利。
首先,產品結構合理,模塊的的職責明確,具有高內聚性,模塊間耦合性較低。程序員能夠更有針對性的編程,更有序地分工合作。
其次,三層架構邏輯上分離了UI設計、領域關係、後臺實現的工作團隊裏各人能專注地做自己的事。例如我們的UI層就分別由兩個同學完成小程序端和後端的任務,他們只需要拿到設計稿和業務文檔就可以進行開發。
最後,層次間的聯繫由一些接口負責,關注這些接口內部的邏輯,可以清楚方便地對接和測試。

VUE 與 Flux 狀態管理的異同

MVC架構我們都知道,當業務邏輯很複雜,model與controller之間的關係也很複雜的時候,我們就會需要統一管理controller(或者是MVP架構裏面的presenter)的變化。這就是所謂狀態管理的出衆,也是二者的相同之處。

不同之處在於解決方案:

flux

它分爲四層:view視圖層、action層、dispatcher派發層、store倉庫層。
狀態發生變化時各層的響應是:view——>action——>dispatcher——>store返回——>dispatcher——>view。
這裏寫圖片描述

vuex

vuex核心是:

  • state:存放多個組件共享的狀態(數據)
  • mutations:存放更改state裏狀態的方法,用於變更狀態,是唯一一個更改狀態的屬性
  • getters:將state中某個狀態進行過濾,然後獲取新的狀態,類似於vue中的computed
  • actions:用於調用事件動作,並傳遞給mutation
  • modules:主要用來拆分state

狀態發生變化時各層的響應是:vueComnent——>(dispatch)Action——>(commit)——>Mutations——>(mutate)State——>(render)VueComponent
這裏寫圖片描述

特別的

vuex多個組件調用一個狀態,將原來組件與組件之間的狀態傳遞改成組件與倉庫之間的傳遞,它適用於構建大型的項目。
如果不是大型項目,使用vuex會使代碼更加繁瑣。vue本身是針對組件編程的框架,層層組件之間的數據傳導相當麻煩。而獨立於組件出現的flux,天然的完成了數據傳導與presenter管理兩個麻煩問題。

參考:
也說說狀態管理flux/redux/vuex
flux,redux,vuex狀態集管理工具之間的區別