從零開始編寫本身的C#框架（28）——建模、架構與框架

　　文章寫到這裏，我一直在猶豫是繼續寫針對中小型框架的設計仍是寫些框架設計上的進階方面的內容？對於中小型系統來講，只要將前面的內容進行一下細化，寫上二三十章具體開發上的細節，來講明這個通用框架怎麼開發的就已徹底足夠了，由於對於中小型系統來講，並非很複雜，簡單的瞭解三層架構就已經夠用了，而使用太多的設計反而有點羅嗦，由於基本上沒有什麼人會爲中小型系統花費太多的設計工做。而對於設計大型平臺的框架設計，又深深感到本身的積累還遠遠不夠，寫出來怕會誤導你們。但不換個思惟來說述也很難說清框架的設計思想，別人拿到一個框架源碼後，也很難讓人能清晰的理解這個框架究竟是什麼東東，怎麼去改造它。因此只能抱着和你們共同窗習的心態，來拋磚引玉，但願能更好的總結一下本身的學習成果，固然有些觀點並不必定是正確的，也但願你們能直接拍磚指出來。

 

前言

　　不少朋友看到標題可能會很奇怪，爲何弄一個開發框架首先要作的是建模？建模就能作一個框架出來嗎？直接的人可能會說，這個2B，設計一個開發框架講解的核心應該是三層、五層架構，每一個層應該有什麼用處，他們之間該如何解耦如何協做調用......

　　若是之前有人告訴我設計一個框架這樣作的話，我也會以爲弄一個開發框架搞得這麼複雜作什麼，直接弄幾個層和工具類出來，而後寫一些常見功能不就好了。

　　實際上寫本系列以來，理論部分一直在琢磨怎麼才能用更通俗易懂的方式講解出來，像前面章節同樣直接從三層架構去講，只能很簡單的說明他們之間的關係，但爲何設計出來的是這樣的框架而不是那樣的？前面章節所作出來的框架能直接用在網站後端管理上，但若是做爲電商平臺、OA、CRM、供應鏈......等軟件框架時行不行？會不會存在問題？要如何去改善？若是開發的框架用於電商平臺，當訪問流量增大，想要增長服務器作分佈式、負載均衡進行數據分流時，是在現有框架上改造令它支持仍是設計一個新的架構呢？要如何改造或如何設計？設計好的架構支持什麼樣的業務？如何讓需求提供者（未技術人員）能更早的參與到架構設計進來？如何儘早發現系統框架的瓶頸？怎麼從設計層就能解決衆多的問題？如何讓新入職人員快速理解並掌握整個框架知識，快速加入開發的隊列中？若是避免核心技術只把握在某一個或幾我的員手中，當這些人中有人離職後其餘人員沒法快速接手的問題？設計的系統可否根據業務拆分爲一個個獨立的模塊，讓測試人員提早加入到項目中，提高項目的質量？拆分的模塊如何統一塊兒來？......越想問題就越多，怎麼去描述都講不到點上。

　　通過知識的不斷積累，慢慢意識到一直以來使用的都是面向過程的方法來分析需求，在作項目或設計架構時，都是爲了功能而設計，爲了設計而設計，並不知道其因此然。若是想作出的框架對於項目來講能作到適用，恰好合適，那就須要真正的去分析需求，根據用戶實際的需求以及發展方向來設計架構，它是面向對象的，使用用例或領域來驅動設計，爲特定需求而定製設計出來的系統，而不是作出來的架構功能過多或未達到設計要求，或者用上一段時間後整個架構甚至數據表都得推倒重來。

　　固然上面所說的都是理想狀態下設計出來的系統，而實際工做中你們開發中的架構或平臺，面對每一次大版本的更新都是欲仙欲死的，呵呵......不少時候都得大動手術，進行大改造。

 

UML、架構與框架的關係

　　度娘上說：

　　Unified Modeling Language (UML)又稱統一建模語言或標準建模語言，它是一個支持模型化和軟件系統開發的圖形化語言，爲軟件開發的全部階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。

　　軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的鏈接則明確和相對細緻地描述組件之間的通信。在實現階段，這些抽象組件被細化爲實際的組件，好比具體某個類或者對象。在面向對象領域中，組件之間的鏈接一般用接口來實現。

　　對於框架來講，就是已作好的鋼筋混凝土結構建築物，裏面能夠建各個功能的停車場、商場、酒店、飯店、商住房......

 

　　架構對於框架來講，它就是繪出好的建築圖紙，它描述建築物的外部形狀、內部佈置、結構構造、內外裝修、材料作法以及設備、施工等各類圖樣。而UML就是在這些圖紙上所繪製的各類形狀的圖形（符號）。

 

　　有不少朋友會說，我不用UML、不懂架構同樣開發出一套套不一樣功能的框架，幹碼要學這麼多，能作出來不就好了唄。的確是這樣的，對於功能簡單、中小型的項目，或本身已作過不少相似框架的架構來講，直接編碼是一個不錯的選擇。而對於一個大型的，或複雜程度很高的，或高風險的，或你徹底不熟悉的領域的項目來講，開發前先作好相關的設計工做，能幫助你下降項目失敗的風險。

　　框架不是萬能的，不是什麼系統都適用，就算是通用的管理權限框架，也有它的侷限性。就好比本系列前面章節所開源的框架代碼，權限管理模塊相對來講比較強大，但也存在着各類弊端。好比說將它用於一個簡單的企業Web站，它屬於過渡設計了，多了不少沒必要要的功能，讓開發變得複雜；而對於一個企業管理軟件來講，它的權限粒度還不夠細，好比須要實現對於不一樣角色的人須要展現不一樣的內容列表就沒有實現到；底層應用的ORM框架也限制了只能使用MsSql數據庫；UI層執行效率慢......因此咱們在設計時，要有針對具體的需求來設計不一樣的架構，合適纔是最好的，而不是不管什麼時候都追求最強大的。

　　架構比如一個軟件的骨架，不一樣的設計適合不同的領域，就好像小鳥的骨架適合飛翔，豹子的骨架適合奔跑同樣，若是設計好的架構要強硬的去改變它適合其餘領域，不是不能夠，這會增長很大的難度，就好像想讓小鳥變得像豹子一個能夠奔跑，又能夠飛翔同樣。

　　在實際的開發過程當中，不少項目不是你一我的就能單獨完成的，在團隊協做開發中，如何能讓你們都明白你的意圖，能配合你將項目開發出來，就須要藉助相關的工具（UML或其餘建模語言），簡單的繪製出業務用例、各類視圖和模型，來幫助你們理解與配合。

　　對於大中小型不一樣的項目來講，花費在架構設計上的時間都是不一樣的，據巴利·玻姆（Barry W. Boehm——軟件工程估算模型COCOMO模型之父、軟件過程螺旋式模型之父）所計算，對於小項目只需投入5%左右的時間；大中型項目須要點總時間的33%~37%的時間；而超大型項目，則需投入40%的時間。

 

建模應用在實際開發中所帶來的好處

　　一、讓非技術人員提早理解所開發出來的系統能處理的業務內容

　　對於非技術人員來講，他們看不懂各類代碼，而業務用例則可讓他們提早理解將要實現的功能是什麼，是否是他們想要的內容。

　　二、讓測試人員能提早參與到項目中

　　當模型建立完成並討論經過後，相關的測試人員就能夠開始編寫測試用例，以及相關的自動化測試接口，讓開發人員提交了解測試的內容與思路，能夠提早參與到測試當中，併爲測試提供更多的意見與角度，提高程序的質量，另外當程序完成開發後，也能立刻運行自動化測試代碼，加快測試進度。

　　三、讓開發人員對所要開發的項目有更深刻的瞭解

　　對於大多項目來講，除了架構的設計者這外，其餘開發人員對於軟件框架了解只是只知其一;不知其二，只熟悉本身那一塊的工做，對其餘模塊瞭解並不太深。這就形成不少溝通上的障礙，就算讓他負責更多的功能模塊開發，也只是讓他了解太更多一點而已，當軟件架構的功能限制對業務擴展的支持，須要改造軟件架構時，幾乎沒幾個開發人員敢去隨便修改底層框架代碼，這主要緣由就是對本身架構並不瞭解，怕改動後影響其餘模塊的正常運行。而有成熟的架構文檔，這將幫助開發人員瞭解軟件框架的運行機制，各模塊、組件以前的關係，讓他們有能力有條件有信心去對軟件框架進行改造。

　　四、讓新加入的開發人員更容易瞭解項目

　　一位新成員加入開發團隊時，最頭痛的就是怎麼快速接手項目，投入到開發中去，而有了相關的架構模型，，開發人員能夠簡單的經過查看架構模型和對應的文檔，快速的瞭解整個開發框架和其技術要點。

　　還有其餘不少好處這裏就不一一訴說了。

 

 版權聲明：

　　本文由AllEmpty原創併發佈於博客園，歡迎轉載，未經本人贊成必須保留此段聲明，且在文章頁面明顯位置給出原文連接，不然保留追究法律責任的權利。若有問題，能夠經過1654937@qq.com 聯繫我，很是感謝。

 

　　發表本編內容，主要是爲了和你們共同窗習共同進步，有興趣的朋友能夠加加Q羣：327360708 ，你們一塊兒探討。

　　在佛山工做的朋友也能夠加入：佛山IT朋友羣 263767221，你們能夠共享資源共同進步，有空你們能夠約出來認識一下，交流一下技術，哈哈

 

　　更多內容，敬請觀注博客：http://www.cnblogs.com/EmptyFS/