分層架構根據相關職責將應用程序模塊切割為多個層次，那么應用程序框架本身還要不要進行層次划分？隨着對應用程序框架的理解加深，以及項目復雜度的提升，為應用程序框架分層就顯得很有必要，它將影響你如何創建VS解決方案。
在剛開始建立應用程序框架時，你首先會想到的是把技術方面的東西抽取出來，放到專門的文件夾，但你很快發現建立一個獨立的.Net類庫更加方便。你平時會把需要用到的東西封裝成Helper扔進去，有時候也會引用一些第三方的程序集。隨着日積月累，這個類庫逐步變得豐富，同時雜草也在滋長，很顯然這時候你還沒有依賴管理的概念。
一個新項目准備啟動，你開始搭建環境，當你引入框架類庫時，發現有一些根本用不上的第三方dll也必須引用進來，比如Microsoft.Office.Interop.Word.dll，你感覺到你的框架類庫完全就是一個大雜燴，必須拆分才行，此時，說明你開始察覺到依賴的存在。
如何拆分這些依賴呢？需要創建更多的類庫，把依賴性較強的部分分離出來。怎樣看出依賴性的強弱？首先考慮是否需要引入.Net Framework之外的程序集，如果需要，肯定是強依賴，這主要是指第三方框架。其次考慮是否需要特定環境支持，比如數據庫操作，Web操作，Windows操作，這些操作都依賴性很強，放到單獨的程序集更好。
隨着應用程序框架的持續積累，框架程序集的數量也在增長，現在你的解決方案每次編譯一下，好幾分鍾動彈不得，雖然你多次懇求老板換台更快的電腦，這樣工作效率更高，不過你的老板是個聰明人，笑着告訴你“嘿嘿，你小子的速度都超過電腦了”。電腦換不成，只好另想辦法，你發現為應用程序框架建立一個獨立的解決方案可以顯著減少VS編譯項目的時間。把應用程序框架與項目分離之后，會發現框架和項目的職責也更加清晰。當下一個項目來臨時，只需要引入相關的DLL即可。
在進行技術積累的同時，你的項目經驗也在不斷增強，發現很多業務知識可以抽取出來，根據之前的經驗，你決定為業務框架專門創建一個VS解決方案。剛開始可能只有一些通用業務類型，比如地址。后面把業務領域一些專業的知識也封裝進去，並創建了不同的程序集。除此之外，你還把第三方的接口也封裝起來，像支付接口，充值接口，商城接口，酒店預訂接口。
可以看到，根據邏輯分類和依賴關系，至少可以把應用程序框架分成技術和業務兩大類，每個大類還會繼續划分，示意圖如下。
新手更傾向於少量的類庫，而老手則會根據依賴創建大量類庫。至於具體創建多少個解決方案和程序集，也完全根據你的習慣而定。
.Net應用程序框架交流QQ群: 386092459，歡迎有興趣的朋友加入討論。