解決方案的結構一般是三個解決方案文件夾，分別是：
Models
ViewModels
Views
當然需要的話可以擴充，如Services、UnitTest等等。
然後每個解決方案文件夾裡面包含各自的項目，項目裡面的命名空間名自動跟隨項目名，而不跟隨解 決方案文件夾名，而且用解決方案文件夾的好處就是解決方案不提供物理管理，只提供邏輯關聯，所以 在項目文件夾裡是找不到解決方案文件夾的；解決方案文件夾可以右鍵直接編譯，不同於普通的物理文 件夾，普通的物理文件夾只能創建在項目下面，裡面不可以再添加項目文件，而且不可以右鍵編譯，這 是他們兩個的區別所在。
Models裡包含的是數據以及數據是怎麼來的，包括訪問數據庫，xml等等，這裡面都是類庫，不涉及 任何UI的東東。
Views裡面包含的是所有的UI，這裡面都是界面，包括字體、Style、圖片、動畫、窗體、用戶控件等 ，數據要怎麼展示給用戶，都在這裡面，並且這裡面只包含“純UI”的代碼，不涉及任何處 理數據的代碼。Views裡面的每個工程的結構一般為：
Fonts
Images
Styles
UserControls
Windows
App.xaml
ViewModels裡包含的是所有的邏輯，Models裡的數據怎麼組織、處理、調用、供給界面展示，都在這 一層，如我之前所說，ViewModel其實意為“Model for View”，View裡的UI全部、或者部分 ，直接、或者間接地把它的DataContext指向這裡，所以這裡的數據、方法、屬性、命令、事件一般是為 Views裡的某個UI定制的，也可以是為某“一群”UI定制，這個看具體的需要，如果很多地方 用到同一個邏輯，不妨抽象出一個公用的ViewModel，如a界面的ComBox要一個部門的列表作為數據源，b 界面也有一個ComBox需要同樣的部門列表，c界面也需要，那就把這個邏輯抽象出來公用。
為何要分出這麼多項目，其實源自於CS程序的軟肋。CS的東東，交付用戶了，很開心，出Bug了，修 改，然後重新發布到用戶手裡，重裝，這是個很費事的過程，不像BS的，完全沒有這困擾。把邏輯從UI 的項目裡抽出來，到最後就是一堆exe和dll，只要不涉及本質性的改動，哪個出問題了改哪個，到時候 直接替換。
另外，每個項目的生成路徑最後都指定到根目錄下的Debug文件夾，方便打包和資源的歸總。並且使 用SVN的話，每個項目下的Debug文件夾是不用提交到服務器的，這個東東每次都會自動生成的。
作者: 熱卡
出處：http://www.cnblogs.com/zoexia/
