應用程式架構實戰八:應用程式架構的層次規劃

標籤：style   blog   http   os   sp   strong   檔案   資料   on   

　　分層架構根據相關職責將應用程式模組切割為多個層次，那麼應用程式架構本身還要不要進行層次劃分？隨著對應用程式架構的理解加深，以及項目複雜度的提升，為應用程式架構分層就顯得很有必要，它將影響你如何建立VS解決方案。

　　在剛開始建立應用程式架構時，你首先會想到的是把技術方面的東西抽取出來，放到專門的檔案夾，但你很快發現建立一個獨立的.Net類庫更加方便。你平時會把需要用到的東西封裝成Helper扔進去，有時候也會引用一些第三方的程式集。隨著日積月累，這個類庫逐步變得豐富，同時雜草也在滋長，很顯然這時候你還沒有依賴管理的概念。

 　　一個新項目準備啟動，你開始搭建環境，當你引入架構類庫時，發現有一些根本用不上的第三方dll也必須引用進來，比如Microsoft.Office.Interop.Word.dll，你感覺到你的架構類庫完全就是一個大雜燴，必須拆分才行，此時，說明你開始察覺到依賴的存在。

　　如何拆分這些依賴呢？需要建立更多的類庫，把依賴性較強的部分分離出來。怎樣看出依賴性的強弱？首先考慮是否需要引入.Net Framework之外的程式集，如果需要，肯定是強依賴，這主要是指第三方架構。其次考慮是否需要特定環境支援，比如資料庫操作，Web操作，Windows操作，這些操作都依賴性很強，放到單獨的程式集更好。

 　　隨著應用程式架構的持續積累，架構程式集的數量也在增長，現在你的解決方案每次編譯一下，好幾分鐘動彈不得，雖然你多次懇求老闆換台更快的電腦，這樣工作效率更高，不過你的老闆是個聰明人，笑著告訴你“嘿嘿，你小子的速度都超過電腦了”。電腦換不成，只好另想辦法，你發現為應用程式架構建立一個獨立的解決方案可以顯著減少VS編譯項目的時間。把應用程式架構與項目分離之後，會發現架構和項目的職責也更加清晰。當下一個項目來臨時，只需要引入相關的DLL即可。

　　在進行技術積累的同時，你的項目經驗也在不斷增強，發現很多業務知識可以抽取出來，根據之前的經驗，你決定為業務架構專門建立一個VS解決方案。剛開始可能只有一些通用業務類型，比如地址。後面把業務領域一些專業的知識也封裝進去，並建立了不同的程式集。除此之外，你還把第三方的介面也封裝起來，像支付介面，儲值介面，商城介面，酒店預訂介面。

　　可以看到，根據邏輯分類和依賴關係，至少可以把應用程式架構分成技術和業務兩大類，每個大類還會繼續劃分，如下。

　　新手更傾向於少量的類庫，而老手則會根據依賴建立大量類庫。至於具體建立多少個解決方案和程式集，也完全根據你的習慣而定。

　　.Net應用程式架構交流QQ群: 386092459，歡迎有興趣的朋友加入討論。

應用程式架構實戰八:應用程式架構的層次規劃