隨著時間的推移，Winform也算是能夠堅持下來最久的技術之一了，它的昔日輝煌和現今的依舊活躍，導致了它依舊擁有者很龐大的用戶群體，雖然目前很多技術日新月異的，曾經的ASP、ASP.NET WebForm、Asp.NET MVC、WPF等技術基本上淡出了視野,而迎來了.NET Core、UWP等技術... ...
隨著時間的推移，Winform也算是能夠堅持下來最久的技術之一了，它的昔日輝煌和現今的依舊活躍，導致了它依舊擁有者很龐大的用戶群體，雖然目前很多技術日新月異的，曾經的ASP、ASP.NET WebForm、Asp.NET MVC、WPF等技術基本上淡出了視野,而迎來了.NET Core、UWP等技術應用，.NET Core也給.NET迎來了一次重要的涅槃重生的契機，可以更高效的運行在各種平臺上，從而激發了.NET的又一春。Winform的技術雖然基本上已經壓縮在一定的範圍內，不過由於的用途廣泛，微軟也無法完全捨棄，據說在即將到來的.NET core 3.0裡面，會支持Winform，那真是非常不錯的一次轉變。
1、Winform的應用場景
我自己也是一個Winform開發的擁躉，基本上十幾年來一直用著Winform開發各種各樣的應用（雖然我也做很多相關的Web開發），從最早的一些小工具，小共用軟體什麼的，到後面給客戶開發一些數據管理系統、業務管理系統等等，因此在這方面使用還算有一定的背景，可以對WInform這個技術應用做一個個人的概括。
1）用戶體驗
在Winform應用裡面，和其他Web系統比起來，它的用戶體驗是最好的，而且界面響應速度也比Web界面來的快捷一些，由於很多情況下，用戶考慮使用方便性，如一些報表的展示、列印、導入導出文件的處理等常規的操作，都還是習慣使用Winform這種定製型非常好的界面來處理，畢竟大多數情況下，單位都有一套業務和數據的管理系統來處理這些業務。
2）數據敏感
另外很多情況下，如一些事業單位、機構什麼，他們的數據是比較敏感的，不希望對外公開，網路的引入會提供數據外泄的可能，另外它們也是經常處於內網的環境下，因此一個單機版的程式就可以搞定他們的日常業務處理了，這種特別的業務環境，註定了使用Winform來處理會更勝一籌。
3）開發便利
Winform開發的程式，發佈共用比較容易，直接安裝就可以使用，可以不需要部署在雲端（雖然我的混合框架方式可以訪問Web API、WCF等服務獲取數據，透明的數據處理）；而且Winform的界面開發起來非常方便，結合界面套件，可以做出非常棒的界面效果。另外從開發角度上講，Web前端的技術淘汰非常快，Winform的技術積累反而是在逐步加固的過程，因此對於一些開發人員來說，迭代Winform開發的應用會更加方便，也更加熟練，因此只要客戶在用，系統相容，這種Winform的程式會一直保留下去。
2、Winform開發的過程
1）界面開發
Winform開發對比其他有不少優點，主要的特點還是開發方便，基於一定的框架，可以快速開發特定的業務管理系統。如下是我客戶關係管理系統的界面效果。主界面是採用了DevExpress套件，可以讓界面看起來非常統一漂亮，另外對於界面的開發，我們可以基於資料庫信息的基礎上，通過工具快速生成常規的列表展示界面，以及編輯界面，從而進行一定的調整即可。
對於列表界面，常規的就是包含數據的分頁展示、查詢、高級查詢、導入、導出、列印等這些常規的功能，這些都可以通過定義好的界面模板進行統一生成，生成後進行一定的調整（如加入左側樹形列列表）即可。
如這個編輯界面，也是基於資料庫信息的生成後進行一定的調整即可。我們可以快速的修改控制項的類型，如修改為下來列表類型，備註類型等，而在代碼中進行字典類型綁定就可以顯示字典數據了。
2）後臺代碼開發
對於一個新建的業務表，我們需要開發的需要底層的實現和界面層的展示，這些工作量也是非常巨大的，如果基於控制項細粒度的處理，也是非常繁瑣的工作，因此基於這些開發過程的考慮，我們引入了提高效率開發的代碼生成工具Database2Sharp，專門為我們基於開發框架基礎上的框架實現代碼開發，和業務界面展示的快速開發。
代碼生成工具，不僅能夠讓它生成我們常規開發的界面層以下的實現代碼（包括BLL、DAL、Entity、IDAL等層，以及混合框架的WCF、Web API的實現層和調用封裝層），以及界面層的調用代碼。
有了這些的處理，我們可極大減輕工作量。
生成的項目中，我們已經有了對應框架支持的實現層了。
普通Winform框架的分層架構圖。
3）底層資料庫支持
在實際需求中，你往往不能決定客戶需要用什麼資料庫，那麼需要根據實際需求或者環境進行資料庫類型的選型，如果是單機版為了方便可以使用SQLite，如果是已有業務系統或者需要響應速度快一些的，那麼考慮使用SQLServer或者Mysql、有些歷史原因的可能會用PostgreSQL或者Oracle等等。那麼框架的彈性就需要支持多種資料庫的了，這種支持不能導致太大的工作量最好，否則會弄得焦頭爛額的。
框架底層資料庫訪問採用了微軟企業庫實現，因此在處理多種資料庫訪問的時候，能夠提供統一的訪問處理操作，同時對不同的資料庫支持操作也是非常不錯的。下圖是框架底層資料庫的支持情況。
採用了微軟企業庫Enterprise Library作為我們底層的資料庫訪問模塊後，對於多種資料庫的訪問操作，就會統一採用這個企業庫的資料庫訪問對象，操作起來非常一致，為了對不同資料庫的常規增刪改查等一些操作進行進一步的封裝，以達到簡化代碼的目的，因此我們可以為每個不同的資料庫定義一個數據訪問操作基類，以便實現一些不同資料庫差異性的處理，但是它們還是有一個共同的數據訪問基類。
採用不同的資料庫，我們需要為不同資料庫的訪問層進行生成處理，如為SQLServer數據的表生成相關的數據訪問層DALSQL，裡面放置各個表對象的內容，不過由於採用了相關的繼承類處理和基於資料庫的代碼生成，需要調整的代碼很少。
4）數據集中的雲端模式
在很多業務系統中，有很多需求是希望部署在雲端伺服器中，這種方式可以實現數據的幾種管理，也有利於安全。因此我們整合了WCF和Web API兩種服務訪問方式，而在開發界面基礎上，不需要太大的變化即可接入，這就是我們的混合開發框架。
混合框架的多種方式支持
而對於WCF或者Web API的封裝，我們是通過介面適配的方式，調用層需要對業務介面進行封裝，從而產生封裝的代碼量。因此可以利用代碼生成工具生成對應業務模塊的介面適配代碼，可以極大減輕對這部分的開發效率損耗。
混合框架的架構如下所示。
代碼生成工具Database2Sharp，生成整體性的混合型框架項目如下所示，只是沒有下圖的界面部分，這部分在實際開發過程中，結合我的混合型框架案例進行整合即可，另外也可以界使用Database2Sharp進行Winform界面的開發，這樣整體性就非常方便操作了：
Winform調用Web API的過程，這個過程可以通過下麵這個圖示進行講解。
5）模塊化的框架結構
在開發Winform應用的時候，我們除了希望簡化代碼外，其實很多常規的業務，我們希望不希望都要重新開發，如許可權管理系統、字典管理、附件管理等，這些是很多業務都涉及到的模塊，我們應該在一定粒度上實現整合現有模塊即可，這樣可以降低我們開發的難度和減少開發時間，我們就可以把重要的時間花在具體的業務領域裡面，快速響應客戶的需求開發。
混合型框架可以看成是Winform框架高級版本，除了它本身是一個完整的業務系統外，它外圍的所有輔助性模塊均（如通用許可權、通用字典、通用附件管理、通用人員管理。。。。）都實現了這種混合型的框架，因此使用非常方便，整個框架如果簡化來看，就是在原有的Winform界面層，用介面調用方式，避免和業務邏輯類的緊耦合關係。
