是否過於“強勢或自以為是”應該作為選擇框架或架構產品的參考標準!

banq發表於2019-06-20

選擇決定使用一個固定的框架將對架構產生重大影響,無論是在短期內將產品按時上市還是長期上市。它可以影響您的應用程式維護和修改的容易程度,是否能滿足不斷變化的需求。答案可能並不總是清晰或簡單,但它會幫助您瞭解何時選擇大型強勢或侵入或自以為是的框架。

在本文中,我們將介紹一些固定的和非固定的框架,以及哪些用例對於採用任何一種方法都有意義。我們還將這種思維應用於更適合作為服務的固定平臺(PaaS)或不太自以為是的基礎架構即服務(IaaS)的案例。這有助於您在構建自己的應用時做出最佳選擇。

什麼是“強勢”框架?

根據定義,框架對架構,最佳實踐和約定做出一些假設。這通常對開發人員和架構師很有幫助,因為它為未來的架構決策提供了一條很好的路徑,它還可以幫助您最終獲得可預測,一致且易於其他開發人員理解的程式碼庫。

但即使使用相同的語言編寫的兩個不同的框架,它們也會在路徑徑完美程度上而有很大的不同。一個框架極端地可以被稱為“自以為是(強勢 侵入性)”。這意味著框架設計者已經建立了一條“快樂的道路”,只要遵循框架設計者的特定的假設, 框架的使用者就可以更容易,更快地進行開發 。當您的需求與框架的目的匹配或一致時,選擇一個自以為是的框架可以極大地促進您的應用程式的開發。強制執行或嚴格約定還可以使新開發人員更容易加入並立即開始提供價值。

但是,它有時也意味著這些假設前提全部有益。這可能意味著實踐中的許多事情,從嚴格或強制約定到缺乏可擴充套件性或可能限制到單個工具集。歸根結底,“自以為是”意味著框架最初是按照最初的預期運作的,並且從中可以看出它有時被迫用很大的痛苦才能完成。

決定使用強勢的框架屬於技術決策,雖然您可以從易於啟動中受益,但是如果您需要擴充套件應用程式超出框架的功能,那麼使用固定框架的決定可能會以未來的代價獲得。

錯誤使用框架的下場:

是否過於“強勢或自以為是”應該作為選擇框架或架構產品的參考標準!

為了增加深度,讓我們看一下前端和後端框架的一些具體示例。我們將看看Angular vs React和Django vs Flask,但這種思路也適用於其他框架,如Vue,Ruby on Rails等等。

Angular vs React

我們會認為React是一個沒有意見(非強勢 非自以為是)的框架,而Angular是一個有強烈主張的框架。兩個框架都能夠建立功能齊全的單頁Web應用程式,並提供豐富的元件庫和大型使用者群。

為了進行比較,讓我們考慮每個框架如何處理資料繫結。Angular提供開箱即用的雙向資料繫結,其中React提供單向資料繫結。為了更深入地瞭解這一點,Angular假定MVVM或MVC型別的架構,並提供模型(資料存在的位置)和檢視(頁面上呈現的內容)之間的雙向連結。這意味著當使用者更改頁面上的內容時,您的模型會自動更新。另一方面,React會強制您自己管理此更新。

作為一個具有強烈意見的框架,Angular會假設您將如何向元件提供資料並使狀態可用。它提供了所有必要的連結,因此您所要做的就是宣告一個變數並在模型中使用它,而不必擔心檢視的更新方式。這稱為資料繫結,它是Angular開箱即用的東西。

另一方面,React不提供此功能,因為您必須顯式處理元件中的更改事件。如果模型更改不是由UI啟動的,則必須通過呼叫setState或使用狀態掛鉤顯式更新狀態,然後狀態掛鉤將自動確保更新檢視。這可以在每個元件中產生更多程式碼,甚至可以使用其他庫(如Redux)來幫助管理跨元件的狀態 - 但它也提供了更高程度的自定義。

React也比Angular輕量,所以如果你不需要Angular的所有整合功能,那麼React可以減少終端使用者的資料使用和載入時間,以及開發應用程式的開發人員的認知負擔。

例如,Angular對網路連線,語言選擇和構建工具鏈做出了類似的假設。當您想要一個“正常工作”的完全整合環境而不必分別考慮每個元件時,這將節省時間。

歸根結底,這取決於偏好。為您做出選擇可以簡化開發並向您傳送規範路徑,這可以為您快速構建應用程式節省大量時間

所有事情都是平等的,並且假設您同時擁有支援Angular和React的開發人員,如果您正在構建快速應用程式原型並且您不想經歷構建React應用程式所需的設定和初始投資的頭痛,Angular是舒適輕鬆的選擇。使用它可以幫助您快速啟動應用程式,因為必須做出更少的決策,並且需要整合更少的程式碼才能找到可行的解決方案。構建工具集對於Angular來說也是非常標準化的,並且存在大量用於快速啟動專案的建立指令碼。

另一方面,如果您知道自己正在開發一個非常自定義的Web /移動應用程式,並且希望能夠靈活地以零散的方式執行操作以建立高效能且功能強大的Web應用程式,那麼React肯定是一個更好的選擇。

Django與Flask

關於DjangoFlask之間的選擇,可以使用不同的用例。Django高度自以為是; Flask不是。

Django為您的所有應用程式提供全功能的體驗,包括ORM,管理皮膚和基於約定的目錄結構。另一方面,Flask提供絕對的簡潔性,高度的控制,並且能夠遵循您喜歡的幾乎任何架構路徑。它的重量也比Django輕,因為它整合了更少的功能。

這兩個框架都在WSGI上執行,並提供開箱即用的模板。

當您構建相當標準的Web應用程式或服務(例如新聞站點,組織網站,電子商務網站或部落格)時,您將希望使用Django。Django提供了大量的示例,入門應用程式,以及一條易於理解的簡單路徑供您遵循。

如果您正在建立具有極少需求的產品,例如小型內部API - 或者如果您需要選擇特定元件(例如自定義身份驗證或資料層訪問),那麼Flask是更好的選擇。它允許您在產品體系結構的每個階段選擇元件。如果您正在構建完全自定義的東西並且您沒有可以遵循的通用功能和架構路徑,那麼它也是更好的選擇。Flask允許您在做出決策時更加靈活,並且不會強迫您按照預定義的路徑進行操作。

PaaS與IaaS

框架可以是固執己見的。您的基礎設施也可以。如果您問自己您的部署平臺有多自以為是,PaaS和IaaS之間的區別變得更加明顯。

PaaS產品為您提供了一個交鑰匙環境,您可以在其中構建應用程式,以便為您管理網路注意事項,基礎架構配置,計算和儲存。在我們的模擬中,PaaS是一種固定的框架,為您做出許多部署和執行時架構假設。Heroku和Elastic Beanstalk是PaaS平臺的示例。您通過PaaS獲得的是一個經濟高效,易於擴充套件的託管平臺,可讓您專注於構建和部署應用程式。

相反,IaaS框架相對不受影響,提供了一個靈活的基礎架構,您可以輕鬆地進行自定義,配置和部署。雖然資料中心和伺服器基礎架構是受管理的,但您必須專門考慮並解決規模調整,容量規劃,基礎架構支援,服務整合和應用程式架構。Microsoft Azure,AWS和GCP都提供IaaS。當靈活性是必需的或應用程式需要時,IaaS是一個很好的選擇:

  • 特定的作業系統
  • 專用的非共享計算環境
  • 資源部署在虛擬網路中
  • 傳統PaaS產品未涵蓋的部署環境

簡單地說,當您想要快速構建產品而不重新發明輪子時使用PaaS,並在有自定義或非標準需求時選擇IaaS。

結論

如果您有明確的目標並且遵循良好的開發或架構路徑,那麼固定框架可以通過使應用程式更易於開發和部署來幫助您節省時間和金錢。一個固定的框架為您提供護欄,大量的入門程式碼,並優化您的路徑。但是如果你知道事情會很快消失,那麼你應該考慮使用一個非自以為是的框架。

例如,如果您想構建一個快速UI或者您知道您的UI將使用標準元件 - 並且您幾乎不需要以非標準方式自定義或更改這些元件的行為 - 那麼可以使用固定框架Angular比React更好的選擇。但是,如果您需要靈活的Python Web框架 - 或者正在構建Django可能沒有示例或開源基本程式碼的自定義產品 - 那麼您可能需要考慮使用非自以為是的Flask。

將看法與不受歡迎的概念擴充套件到部署選項為我們提供了一種方便的方式來檢視PaaS與IaaS。如果你想要一個交鑰匙環境,你應該考慮像Heroku這樣的自以為是的PaaS選項。對於高度定製的需求,請考慮IaaS的靈活性。

相關文章