這段時間在忙着給公司，一個WPF項目做一些功能，該項目的背景介紹
- 兩年以上的運維和迭代歷史
- 有一點點“三層”架構感覺，有View（WPF具體窗口，基本上所有邏輯多在這），Model（沒有明確的定義ViewModel，還是數據Model），Bll（提供給View 的是DataSet，DataTable，只是一個提供數據給View封裝的地方）
- 由於是C/S結構的項目，部署環境考慮，通過WebService 來實現程序和數據庫溝通，提供的數據結構，是不易於操作的DataSet，DataTable。
- 對象實例化都是通過，單例模式，未加Lock考慮，業務類職責不單一。
- WPF窗口后台邏輯太多，各種私有方法，各種事件，堆積在里面，一個窗口后端代碼行數 700~1000 之多。
- 功能開發前期，分析不夠，沒有考慮將來的發展設計開發，導致后期運維，在原來的功能上改來改去，是原來成熟功能模塊出Bug風險增加。
- 沒有經過測試流程匆匆發布上線
綜上，就是現在這個項目技術背景，和一些現狀。
我是因為在里面新增了幾個功能模塊，在過程中發現開發起來太痛苦，太吃力，才萌生了想重構這個項目想法，但是由於項目還在使用，而且一種特殊環境下，比較依賴一個系統，不能夠一下全部重構了，只能一步一步來，在實踐中進行重構（拿了一個用戶不會使用，但是開發人員會用來配置的功能模塊）。
一．已經重構的部分
- 新增DataSet，DataTable，DataRow 轉換成實體集合和實體 擴展的公共的 Dll（為什么要單獨Dll呢，以后所有的擴展方法多可以放在里面，不過我還是給大家推薦一個開源的，寫的不錯的組件，Z.ExtensionMethods 很牛逼哦，我這個DLL也是參照他的源碼寫的），之所有要單獨加這么Dll，主要有幾個用途
(1) 原來的轉成實體這個工具，在應用層，就是具體WPF項目，就不能夠給BLL 使用，會出現循環引用的問題。
(2) 我的想法是BLL 要回歸它應盡責任上來，負責邏輯的事情，而不是單單去調用一下WebServices 把DataSet，DataTable 直接再轉到應用層去，現階段重構任務是想把調用WebService 返回DataSet，DataTable，轉到 實體&實體集合，畢竟操作實體比DataSet，DataTable 用得多，首先更加接近於OOP思想，編寫邏輯更加得心應手。
- 新增 ViewModel Dll，由於原來Model 沒有准確定義到底是視圖模型，還是數據模型，結構也是比較亂，也不想動到里面東西，而影響其他功能，所有單獨新增了這么一個ViewModel 層，來負責視圖與Bll 直接數據交互。
- 把原來Bll 層，責任擔當給提起來，將WebService 返回DataSet，DataTable 轉換成實體&實體集合，把應用層后端業務邏輯，移到BLL層。
- 建立開發版，測試版，發布版分支，嚴格走測試流程。
二．未重構的部分的一些想法
- 業務層，具體每個類，實例化都用單例模式，從直觀來講，業務類不應該自己負責實作實例化工作的代碼，而應該交由使用方來實作。（其他什么高深理解我暫時沒有。。），所有將來我的想法
(1) 新增 業務接口組件，與現在業務層呼應
(2) 在應用層，通過IOC 框架，依賴注入來實例化具體業務邏輯，計划使用Autofac 組件。
- WebService 換成WebApi，主要考慮WebService 太過笨重，對於這種C/S 架構的項目，我覺得用WebApi 提供json 數據結構，會比較輕量，易於操作，性能也好點，特別是現在JSON 比 XML 流行的時代
- WebApi 負責提供數據，但是不再是DataSet，DataTable 數據結構，而是Json。再編寫一個HttpClient 幫助類庫，來封裝調用WebApi 方法，且利用方能的泛型，將Json序列化成具體 實體&實體集合。
- 利用MVP & MVVM 架構模型，來架構更加清爽點，比喻窗口中 控件事件，其他的一些控制邏輯，移到具體的一層里面，是窗口不至於太多代碼。
- 功能實現時，把用到相關部分盡量設想未來是否在哪里也能夠使用到，要封裝成公用的組件，以供其他功能重用。
- 業務邏輯層，盡量做單元測試。減少Bug產生幾率，提供項目品質。
以上最近項目中的總結和想法，由於能力有限，有些地方還只是想，沒有實踐過，希望大家多交流。