Angular應用架構設計-5:設計原則與總結

這是有關Angular應用架構設計系列文章中的一篇，在這個系列當中，我會結合這近兩年中對Angular、Ionic、甚至Vuejs等框架的使用經驗，總結在應用設計和開發過程中遇到的問題、和總結的經驗，來說一下Angular應用的架構設計相關的一些問題，包括像元件設計、元件之間的資料互動與通訊、Ngrx Store的使用、Rxjs的使用與響應式程式設計思想。這些設計思想和方法，不僅適用於Angular，也適用於Vuejs、React等前端框架。當然，應用架構設計沒有一個放之四海皆準的標準，他只能是根據具體情況具體分析。如果大家有更好的想法，歡迎交流。

5. Angular應用架構設計-5:設計原則

最後在總結一下架構設計的原則。

低耦合可維護的元件

在之前的文章中，我們多次提到解耦、低耦合、減少依賴。

如果兩個元件直接的依賴太多，有太多的相互呼叫、相互取值，那麼當我的一個元件修改的時候，其他的元件也要做相應的修改。

層與層之間的依賴更加重要，如展示層和控制層，我們在展示層顯示資料，在控制層處理業務、讀寫資料等。我們開發一個應用，也別是一個長期維護的產品時，業務邏輯肯定經常修改，相應的展示方式也會修改。如果我們能把展示層和控制層的隔離控制的很好，控制層只把需要展示的資料暴露出來，給頁面需要相應的事件提供相應的介面，其他所有的控制、判斷、處理都隱藏在內部。就會減少很多由於一點業務邏輯的修改而導致的Service和元件裡的大量修改。

可測試的程式碼結構

控制層和展示層的隔離，還還來一個好處就是控制層程式碼的可測試性。一個Service類，就是一個簡單的物件，我們可以很方便的用Angular提供的方式建立，並透過設定測試資料狀態、呼叫業務方法、檢查結果狀態，來測試我們的邏輯。如果我們的Service類能夠很好地測試，那麼剩下的就只是把資料繫結到模板上。如果我們在展示層寫了很多邏輯、判斷等，那麼就勢必要針對元件進行測試，要對顯示到頁面上的資料進行判斷，這就需要使用phantomJs之類的記憶體瀏覽器執行，結果的驗證也比較麻煩。

除了分層的軟體架構設計，我們還需要在實現控制層程式碼的時候，透過使用一些設計模式，合理的程式碼結構，讓我們的程式碼可測試。有關設計模式和程式碼結構的原則，很多時候可以參考物件導向的設計原則。其中一個很重要的原則就是，一個方法就做一件事情，然後再透過適當的設計模式將這些方法組合起來。我們測試的時候，首先測試這些一個個方法的正確性，然後再測試把這些方法串起來的流程的正確性。這樣就能保證整個業務的正確性。

最後，再說一下優秀程式設計師跟三流二手程式設計師的區別，優秀的程式設計師先設計再編碼，二手程式設計師是先編碼再改bug。

歡迎關注課程