從零開始編寫自己的C#框架（28）——建模、架構(gòu)與框架

　　文章寫到這里，我一直在猶豫是繼續(xù)寫針對(duì)中小型框架的設(shè)計(jì)還是寫些框架設(shè)計(jì)上的進(jìn)階方面的內(nèi)容？對(duì)于中小型系統(tǒng)來說，只要將前面的內(nèi)容進(jìn)行一下細(xì)化，寫上二三十章具體開發(fā)上的細(xì)節(jié)，來說明這個(gè)通用框架怎么開發(fā)的就已完全足夠了，因?yàn)閷?duì)于中小型系統(tǒng)來說，并不是很復(fù)雜，簡(jiǎn)單的了解三層架構(gòu)就已經(jīng)夠用了，而使用太多的設(shè)計(jì)反而有點(diǎn)羅嗦，因?yàn)榛旧蠜]有什么人會(huì)為中小型系統(tǒng)花費(fèi)太多的設(shè)計(jì)工作。而對(duì)于設(shè)計(jì)大型平臺(tái)的框架設(shè)計(jì)，又深深感到自己的積累還遠(yuǎn)遠(yuǎn)不夠，寫出來怕會(huì)誤導(dǎo)大家。但不換個(gè)思維來講述也很難說清框架的設(shè)計(jì)思想，別人拿到一個(gè)框架源碼后，也很難讓人能清晰的理解這個(gè)框架到底是什么東東，怎么去改造它。所以只能抱著和大家共同學(xué)習(xí)的心態(tài)，來拋磚引玉，希望能更好的總結(jié)一下自己的學(xué)習(xí)成果，當(dāng)然有些觀點(diǎn)并不一定是正確的，也希望大家能直接拍磚指出來。

前言

　　很多朋友看到標(biāo)題可能會(huì)很奇怪，為什么弄一個(gè)開發(fā)框架首先要做的是建模？建模就能做一個(gè)框架出來嗎？直接的人可能會(huì)說，這個(gè)2B，設(shè)計(jì)一個(gè)開發(fā)框架講解的核心應(yīng)該是三層、五層架構(gòu)，每個(gè)層應(yīng)該有什么用處，他們之間該如何解耦如何協(xié)作調(diào)用......

　　如果以前有人告訴我設(shè)計(jì)一個(gè)框架這樣做的話，我也會(huì)覺得弄一個(gè)開發(fā)框架搞得這么復(fù)雜做什么，直接弄幾個(gè)層和工具類出來，然后寫一些常見功能不就行了。

　　實(shí)際上寫本系列以來，理論部分一直在琢磨怎么才能用更通俗易懂的方式講解出來，像前面章節(jié)一樣直接從三層架構(gòu)去講，只能很簡(jiǎn)單的說明他們之間的關(guān)系，但為什么設(shè)計(jì)出來的是這樣的框架而不是那樣的？前面章節(jié)所做出來的框架能直接用在網(wǎng)站后端管理上，但如果作為電商平臺(tái)、OA、CRM、供應(yīng)鏈......等軟件框架時(shí)行不行？會(huì)不會(huì)存在問題？要如何去改善？如果開發(fā)的框架用于電商平臺(tái)，當(dāng)訪問流量增大，想要增加服務(wù)器做分布式、負(fù)載均衡進(jìn)行數(shù)據(jù)分流時(shí)，是在現(xiàn)有框架上改造令它支持還是設(shè)計(jì)一個(gè)新的架構(gòu)呢？要如何改造或如何設(shè)計(jì)？設(shè)計(jì)好的架構(gòu)支持什么樣的業(yè)務(wù)？如何讓需求提供者（未技術(shù)人員）能更早的參與到架構(gòu)設(shè)計(jì)進(jìn)來？如何盡早發(fā)現(xiàn)系統(tǒng)框架的瓶頸？怎么從設(shè)計(jì)層就能解決眾多的問題？如何讓新入職人員快速理解并掌握整個(gè)框架知識(shí)，快速加入開發(fā)的隊(duì)列中？如果避免核心技術(shù)只把握在某一個(gè)或幾個(gè)人員手中，當(dāng)這些人中有人離職后其他人員無法快速接手的問題？設(shè)計(jì)的系統(tǒng)能否根據(jù)業(yè)務(wù)拆分為一個(gè)個(gè)獨(dú)立的模塊，讓測(cè)試人員提前加入到項(xiàng)目中，提升項(xiàng)目的質(zhì)量？拆分的模塊如何統(tǒng)一起來？......越想問題就越多，怎么去描述都講不到點(diǎn)上。

　　經(jīng)過知識(shí)的不斷積累，慢慢意識(shí)到一直以來使用的都是面向過程的方法來分析需求，在做項(xiàng)目或設(shè)計(jì)架構(gòu)時(shí)，都是為了功能而設(shè)計(jì)，為了設(shè)計(jì)而設(shè)計(jì)，并不知道其所以然。如果想做出的框架對(duì)于項(xiàng)目來說能做到適用，剛好合適，那就需要真正的去分析需求，根據(jù)用戶實(shí)際的需求以及發(fā)展方向來設(shè)計(jì)架構(gòu)，它是面向?qū)ο蟮模褂糜美蝾I(lǐng)域來驅(qū)動(dòng)設(shè)計(jì)，為特定需求而定制設(shè)計(jì)出來的系統(tǒng)，而不是做出來的架構(gòu)功能過多或未達(dá)到設(shè)計(jì)要求，或者用上一段時(shí)間后整個(gè)架構(gòu)甚至數(shù)據(jù)表都得推倒重來。

　　當(dāng)然上面所說的都是理想狀態(tài)下設(shè)計(jì)出來的系統(tǒng)，而實(shí)際工作中大家開發(fā)中的架構(gòu)或平臺(tái)，面對(duì)每一次大版本的更新都是欲仙欲死的，呵呵......很多時(shí)候都得大動(dòng)手術(shù)，進(jìn)行大改造。

UML、架構(gòu)與框架的關(guān)系

　　度娘上說：

　　Unified Modeling Language (UML)又稱統(tǒng)一建模語言或標(biāo)準(zhǔn)建模語言，它是一個(gè)支持模型化和軟件系統(tǒng)開發(fā)的圖形化語言，為軟件開發(fā)的所有階段提供模型化和可視化支持，包括由需求分析到規(guī)格，到構(gòu)造和配置。

　　軟件架構(gòu)是一個(gè)系統(tǒng)的草圖。軟件架構(gòu)描述的對(duì)象是直接構(gòu)成系統(tǒng)的抽象組件。各個(gè)組件之間的連接則明確和相對(duì)細(xì)致地描述組件之間的通訊。在實(shí)現(xiàn)階段，這些抽象組件被細(xì)化為實(shí)際的組件，比如具體某個(gè)類或者對(duì)象。在面向?qū)ο箢I(lǐng)域中，組件之間的連接通常用接口來實(shí)現(xiàn)。

　　對(duì)于框架來說，就是已做好的鋼筋混凝土結(jié)構(gòu)建筑物，里面可以建各個(gè)功能的停車場(chǎng)、商場(chǎng)、酒店、飯店、商住房......

　　架構(gòu)對(duì)于框架來說，它就是繪出好的建筑圖紙，它描述建筑物的外部形狀、內(nèi)部布置、結(jié)構(gòu)構(gòu)造、內(nèi)外裝修、材料做法以及設(shè)備、施工等各種圖樣。而UML就是在這些圖紙上所繪制的各種形狀的圖形（符號(hào)）。

　　有很多朋友會(huì)說，我不用UML、不懂架構(gòu)一樣開發(fā)出一套套不同功能的框架，干碼要學(xué)這么多，能做出來不就行了唄。的確是這樣的，對(duì)于功能簡(jiǎn)單、中小型的項(xiàng)目，或自己已做過很多類似框架的架構(gòu)來說，直接編碼是一個(gè)不錯(cuò)的選擇。而對(duì)于一個(gè)大型的，或復(fù)雜程度很高的，或高風(fēng)險(xiǎn)的，或你完全不熟悉的領(lǐng)域的項(xiàng)目來說，開發(fā)前先做好相關(guān)的設(shè)計(jì)工作，能幫助你降低項(xiàng)目失敗的風(fēng)險(xiǎn)。

　　框架不是萬能的，不是什么系統(tǒng)都適用，就算是通用的管理權(quán)限框架，也有它的局限性。就比如本系列前面章節(jié)所開源的框架代碼，權(quán)限管理模塊相對(duì)來說比較強(qiáng)大，但也存在著各種弊端。比如說將它用于一個(gè)簡(jiǎn)單的企業(yè)Web站，它屬于過渡設(shè)計(jì)了，多了很多不必要的功能，讓開發(fā)變得復(fù)雜；而對(duì)于一個(gè)企業(yè)管理軟件來說，它的權(quán)限粒度還不夠細(xì)，比如需要實(shí)現(xiàn)對(duì)于不同角色的人需要展示不同的內(nèi)容列表就沒有實(shí)現(xiàn)到；底層應(yīng)用的ORM框架也限制了只能使用MsSql數(shù)據(jù)庫；UI層執(zhí)行效率慢......所以我們?cè)谠O(shè)計(jì)時(shí)，要有針對(duì)具體的需求來設(shè)計(jì)不同的架構(gòu)，合適才是最好的，而不是無論何時(shí)都追求最強(qiáng)大的。

　　架構(gòu)好比一個(gè)軟件的骨架，不同的設(shè)計(jì)適合不一樣的領(lǐng)域，就好像小鳥的骨架適合飛翔，豹子的骨架適合奔跑一樣，如果設(shè)計(jì)好的架構(gòu)要強(qiáng)硬的去改變它適合其他領(lǐng)域，不是不可以，這會(huì)增加很大的難度，就好像想讓小鳥變得像豹子一個(gè)可以奔跑，又可以飛翔一樣。

　　在實(shí)際的開發(fā)過程中，很多項(xiàng)目不是你一個(gè)人就能單獨(dú)完成的，在團(tuán)隊(duì)協(xié)作開發(fā)中，如何能讓大家都明白你的意圖，能配合你將項(xiàng)目開發(fā)出來，就需要借助相關(guān)的工具（UML或其他建模語言），簡(jiǎn)單的繪制出業(yè)務(wù)用例、各種視圖和模型，來幫助大家理解與配合。

　　對(duì)于大中小型不同的項(xiàng)目來說，花費(fèi)在架構(gòu)設(shè)計(jì)上的時(shí)間都是不同的，據(jù)巴利·玻姆（Barry W. Boehm——軟件工程估算模型COCOMO模型之父、軟件過程螺旋式模型之父）所計(jì)算，對(duì)于小項(xiàng)目只需投入5%左右的時(shí)間；大中型項(xiàng)目需要點(diǎn)總時(shí)間的33%~37%的時(shí)間；而超大型項(xiàng)目，則需投入40%的時(shí)間。

建模應(yīng)用在實(shí)際開發(fā)中所帶來的好處

　　1、讓非技術(shù)人員提前理解所開發(fā)出來的系統(tǒng)能處理的業(yè)務(wù)內(nèi)容

　　對(duì)于非技術(shù)人員來說，他們看不懂各種代碼，而業(yè)務(wù)用例則可以讓他們提前理解將要實(shí)現(xiàn)的功能是什么，是不是他們想要的內(nèi)容。

　　2、讓測(cè)試人員能提前參與到項(xiàng)目中

　　當(dāng)模型創(chuàng)建完成并討論通過后，相關(guān)的測(cè)試人員就可以開始編寫測(cè)試用例，以及相關(guān)的自動(dòng)化測(cè)試接口，讓開發(fā)人員提交了解測(cè)試的內(nèi)容與思路，可以提前參與到測(cè)試當(dāng)中，并為測(cè)試提供更多的意見與角度，提升程序的質(zhì)量，另外當(dāng)程序完成開發(fā)后，也能馬上運(yùn)行自動(dòng)化測(cè)試代碼，加快測(cè)試進(jìn)度。

　　3、讓開發(fā)人員對(duì)所要開發(fā)的項(xiàng)目有更深入的了解

　　對(duì)于大多項(xiàng)目來說，除了架構(gòu)的設(shè)計(jì)者這外，其他開發(fā)人員對(duì)于軟件框架了解只是一知半解，只熟悉自己那一塊的工作，對(duì)其他模塊了解并不太深。這就造成很多溝通上的障礙，就算讓他負(fù)責(zé)更多的功能模塊開發(fā)，也只是讓他了解太更多一點(diǎn)而已，當(dāng)軟件架構(gòu)的功能限制對(duì)業(yè)務(wù)擴(kuò)展的支持，需要改造軟件架構(gòu)時(shí)，幾乎沒幾個(gè)開發(fā)人員敢去隨便修改底層框架代碼，這主要原因就是對(duì)自己架構(gòu)并不了解，怕改動(dòng)后影響其他模塊的正常運(yùn)行。而有成熟的架構(gòu)文檔，這將幫助開發(fā)人員了解軟件框架的運(yùn)行機(jī)制，各模塊、組件之前的關(guān)系，讓他們有能力有條件有信心去對(duì)軟件框架進(jìn)行改造。

　　4、讓新加入的開發(fā)人員更容易了解項(xiàng)目

　　一位新成員加入開發(fā)團(tuán)隊(duì)時(shí)，最頭痛的就是怎么快速接手項(xiàng)目，投入到開發(fā)中去，而有了相關(guān)的架構(gòu)模型，，開發(fā)人員可以簡(jiǎn)單的通過查看架構(gòu)模型和對(duì)應(yīng)的文檔，快速的了解整個(gè)開發(fā)框架和其技術(shù)要點(diǎn)。

　　還有其他很多好處這里就不一一訴說了。

版權(quán)聲明：　　本文由AllEmpty原創(chuàng)并發(fā)布于博客園，歡迎轉(zhuǎn)載，未經(jīng)本人同意必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，否則保留追究法律責(zé)任的權(quán)利。如有問題，可以通過1654937@QQ.com 聯(lián)系我，非常感謝。

　　發(fā)表本編內(nèi)容，主要是為了和大家共同學(xué)習(xí)共同進(jìn)步，有興趣的朋友可以加加Q群：327360708 ，大家一起探討。

　　在佛山工作的朋友也可以加入：佛山IT朋友群 263767221，大家可以共享資源共同進(jìn)步，有空大家可以約出來認(rèn)識(shí)一下，交流一下技術(shù)，哈哈

　　更多內(nèi)容，敬請(qǐng)觀注博客：http://www.survivalescaperooms.com/EmptyFS/