為什麼要學習樣式與架構知識以及如何開始

專案發展的成功與否,一部份取決於開發人員駕馭系統複雜度的能力,另外一部份則是良好的擴充彈性。應用程式規模逐步擴充的過程中,為了控制衍生的複雜度,我們需要適當的導入樣式與架構設計,一方面將系統複雜度維持在可以控制的程度,同時有助於提升系統未來維護與擴充的彈性。


面對專案開發,初級的 ASP.NET MVC 程式設計師,通常是以資料庫中的資料表結構為基礎來設計應用程式,並針對所要處理的問題定義流程,組織邏輯功能類別,最後這些類別群組形成整個專案的系統架構,當系統規模開始成長,這會讓應用程式變得複雜而難以維護及擴充。


我們可以透過切割商業邏輯,針對每一種特定的問題,發展相對應的領域模型進行處理,如此一來可以更妥善的處理系統擴張後可能增加的複雜度,應用程式將更容易應付大規模發展的挑戰,相較於 ADO.NET 的時代,設計領域模型的過程在近年導入 Entity Framework 之後,變得更為容易處理。


Visual Studio 專案的預設樣板,以 Models/Views/Controllers 切割 ASP.NET MVC 專案內容,對於小型的專案開發非常方便,若是發展更為大型的應用,通常會進一步分層切割專案內容,並以獨立專案建立功能單元,再透過引用進行整合。


真實的世界裏,平房、二十層的辦公大樓,台北一O一,不同規模的建築實體,軟體工程的作法亦會隨著調整,建築公司不會用施作平房的工法來建構辦公大樓,同樣的,台北一O一則需要更複雜的架構設計。

三層式架構是一般常見的分層設計,至於更複雜的大型應用開發,可以透過領域模型為核心的分層概念進行設計,適當的根據所要開發的專案規模,採用合適的分層技巧,是開發人員必須需具備的觀念與能力。

回到一開始提及的複雜度以及彈性,透過領域模型以及分層架構技術的導入,應用程式因此具備了設計上的彈性,透過各種樣式的採用,標準化商業流程,如此一來,開發人員才能從容的應付系統的擴張,駕馭大型應用的開發。

從介面與物件導向設計原則開始樣式與架構知識的學習之路

物件導向設計透過類別的建立支援應用程式功能的開發需求,然而應用程式規模的擴張,會因為類別數量的上升而變得難以維護與擴充。

初期開發人員透過類別繼承的運用,降低類別的數量與複雜度,更進一步的則需要善用介面設計,避免類別彼此的牽制、維持良好的擴充彈性。




介面隱藏類別的實作,僅提供功能介面,外部程式碼面對的是介面公開的規格,並不會直接操作類別實體,類別本身就如同一個黑盒子,無法由外部直接存取,一旦發生任何問題、進行任何的擴充或修改,只需維持介面的規格,客戶端的程式碼並不需要調整,即可達到應用程式更新的目的。

介面另外的優勢是可以多重實作,這讓應用程式得以進一步透過介面隔離原則,將複雜的功能規格切割至不同的介面,再由同一個類別進行實作,提供完整的功能物件,這對於需要提供基礎與進階複雜功能的情形下特別有用。

樣式的發展,均是根植於類別的重用與介面規格抽離,而這些基礎則來自於物件導向設計原則,因此想要學習樣式知識,並將其運用在實際的開發,除了打好物件導向設計的基礎之外,接下來就是嘗試瞭解 SOLID 設計原則。



所謂的 SOLID 表示五個最重要的物件導向設計原則,由每個原則名稱的第一個字母組合而成,列舉如下:
  • 單一職掌原則 (SRP)
  • 開放-封閉原則 (OCP)
  • Liskov 替換原則 (LSP)
  • 介面隔離原則 (ISP)
  • 相依性反轉原則 (DIP)

由上到下,愈下方的原則愈複雜,且會運用到上方的原則,這一部份在「C# 物件導向程式設計」裏有相關的討論,而為了學習完整性,「物件導向設計原則」亦同時收錄於書中,完成設計原則的學習,接下來就可以在相關的基礎上,進入樣式的學習,最終在適當時機,將學習到的實作技巧與知識,整合進架構中進行運用。

具備足夠的「物件導向程式設計」基礎下,逐步建立樣式與架構設計的知識還算容易,比較困難的是在實作上的運用,這必須開發經驗的累積,圖書《商業級 ASP.NET MVC 樣式與架構實務 提供快速系統化學習的教學內容。

沒有留言: