wuhuacong(伍華聰)的專欄

軟件開發有點類似于藝術品的雕刻，需要不斷的打磨。在我們基于一套成熟的架構開發一套軟件后，往往都還是需要反復的推敲，進行不斷的重構優化，使得重復的代碼、硬編碼等地方越來越少，也使得某些邏輯越來越有彈性化。軟件開發和藝術品又有所不同，藝術品可能很容易完工并封刀，而軟件開發卻是持續的改進，軟件最終的持續改進會變為產品化的歸宿，而軟件本身可以從很多維度進行不斷的優化和重構。

軟件開發有點類似于藝術品的雕刻，需要不斷的打磨。在我們基于一套成熟的架構開發一套軟件后，往往都還是需要反復的推敲，進行不斷的重構優化，使得重復的代碼、硬編碼等地方越來越少，也使得某些邏輯越來越有彈性化。軟件開發和藝術品又有所不同，藝術品可能很容易完工并封刀，而軟件開發卻是持續的改進，軟件最終的持續改進會變為產品化的歸宿，而軟件本身可以從很多維度進行不斷的優化和重構。

1、多數據庫支持的設計

一個良好的產品，可能往往需要支持多種數據庫的接入，根據實際業務的需要進行調整，有時候可能需要2到3種數據庫的支持。

在Winform框架上，基于微軟企業庫的底層數據處理，其本身內在支持或者擴展支持多數據庫的統一模型接入，因此我們可以在不同的DAL 分層上進行一些擴展的、特定數據庫的實現即可。

后來繼續開發基于SqlSugar的開發框架的時候，也是希望一個框架支持多種數據庫的，而SqlSugar本身它很容易支持接入多種數據庫，包括上面的各種類型數據庫。

由于SQLSugar的表和字段信息，都是通過特性描述的方式定義的，它們在不同的數據庫是通用的，而我們要做的就是在啟動的時候，加載不同的數據庫連接字符串，進行初始化即可，如下我們定義了基于.netcore的Web API配置信息。

 而對于.netFramework的Winform等程序，我們使用App.Config的配置文件來定義。

我們在數據操作的Crud基類里面，通過不同連接字符串的方式，構建不同的數據庫處理，因此需要通過工廠方式進行構建，如下所示。

有了這些底層的支持，我們只需要在基類函數里面定義好相關的標準處理：如增、刪、改、查、分頁、導入、導出、排序等通用接口，以及針對不同業務模塊，提供一個接口的擴展和實現即可，如下設計圖所示。

針對MongoDB的NoSQL類型數據庫，我們可以提供另外一個類似的基類實現封裝處理，來簡化子類代碼。

 這樣我們同樣實現了對多種數據庫的支持。

 

 

2、多種數據接入方式的處理

除了對不同數據庫類型的接入外，我們試著提高一個維度來查看。我們的數據可能來自本地數據庫，也可能來自Web  API 的接口，還有可能來自WCF服務等其他服務接口。如果他們都實現了相關的接口，那么我們需要使用一個類似開關的方式來切換接受不同的數據處理通道。

例如在我們《Winform混合開發框架》中，支持Web API、WCF數據訪問、直接數據訪問三種方式接入，可以自由切換。它的設計模式是通過一個開關方式進行切換。

我們以字典模塊業務的實現為例，它們在數據庫訪問方式、Web API訪問方式、WCF訪問方式，都是基于同一接口進行的不同實現，因此他們的接口關系圖可以用下面的方式來表述。

 

而我們在此基礎上開發的《基于SqlSugar的Winform端開發框架》，我們依舊采用這個模式來自由切換本地數據庫模式或Web API的訪問方式。如下所示。

 而對應Web API的代理調用類，那么為了極大的重用常規的接口處理，我們需要類似的繼承關系。

在Web API的服務端中，我們為了重用，也是以基類和接口的方式來統一處理相關的邏輯。如我們根據項目的需要，定義了一些Web API控制器的基類，用于實現不同的功能。

而對于 MongoDB的Web API控制器，我們為了方便開發，也設計了同類型的Web API 控制器基類。

 同樣，BS的前端和移動端，我們根據框架后端的接口進行前端JS端的類的封裝處理，引入了ES6類的概念實現業務基類接口的統一封裝，簡化代碼。

對于Python的數據表操作，一樣是可以借鑒上面的基類封裝方式，降低子類代碼的編寫，有利于前端后端的相同接口處理。

 我們從上面可以看到，不管對于終端的調用（Vue3的TS客戶端、WInform端、WPF端、Python前端后端）都是以一定的基類抽象的方式，盡可能的封裝相同邏輯接口的實現，通過泛型類的引入，可以非常彈性化接口的實現處理。

 

3、前端界面的基類抽象

要降低一個程序的編碼數量，提高開發效率，很大程度上就是提高基類的通用性和封裝邏輯，通過重用具體的實現或者重用一定的邏輯，可以大大降低重復代碼的編寫，提高代碼的可讀性和可維護性。

前面介紹了，對于多種數據庫，如SqlServer、Mysql、Oracle、Sqlite、PostgreSQL、達夢數據庫等的接入，我們把關系型數據庫的接入抽象為一個基類，來封裝絕大多數的數據處理，而對于NoSQL數據庫，可以參考類似的實現獨立在處理一個基類。

對于更高一層如WCF、Web API、數據庫訪問的封裝調用，我們可以包裝一層來使它們的數據訪問透明化，通過開發的方式來決定具體的調用方式。

在Web API實現中，我們也通過對控制器基類統一封裝，實現了常規的接口處理和數據的封裝調用。

我們這里繼續介紹一下基類的重要性，基于前端界面來對基類進行不同的封裝處理。

在前端界面中，一般我們把不同的視圖窗口歸類，有些是列表查詢展示的，有些是單條記錄展示的，有些則是自定義用戶控件元素的，因此他們可以分為幾類進行不同的封裝。

我們把常規的列表界面，新增、編輯、查看、導入等界面放在一起，除了列表頁面，其他內容以彈出層對話框的方式進行處理，如下界面示意所示。

對于Winform界面來說，我們為它們設計了不同的基類，以便一些相同內容的處理。

 對于WPF的前端來說，它是基于MVVM的模式的。整個視圖模型ViewModel的繼承關系如下所示。對于不同的業務類，我們也只需要根據實際情況，生成對應的業務視圖模型類即可。

 對于WxPython、PySide的跨平臺Python前端來說，我們也是依照類似的不同窗體來進行不同的基類封裝，提高代碼的重用，并降低子對話框或者列表等子類界面元素的復雜度和代碼量。

對于一個復雜的界面處理，我們還可以逐步細分他們的一些重復性元素，可以重用，也方便減少模塊的代碼，降低關注點。

如對于一個機構信息展示內容來說，可能包括了組織成員的信息，角色信息等，我們可以把它們逐一細化，細化的尺度以最大程度的重用代碼為核心。

如一個角色的信息，可能包括多個方面，我們把它們按照一定的邊界進行劃分不同的用戶控件，實現重用或者減少一個復雜模塊的代碼量。

有些模塊，如上傳文件的處理，我們還可以通過開關配置的方式，實現類似于多數據庫接入的那種方式。根據配置信息來確定上傳的處理路徑選擇，就是一種簡單的工廠設計模式。

如果我們在業務模塊的基礎上進行劃分，還可以針對不同的業務來封裝相關的模塊組件，這樣可以橫向切割一個大的系統為不同的業務模塊。

 基于Winform，通過數據庫或WebAPI數據訪問的Winform前端。

基于CommunityToolkit.Mvvm 、lepoco/wpfui 、HandyControl幾個基礎框架整合的WPF前端界面如下所示。

 基于Vue3+ElementPlus+TypeScript的BS前端

基于Python+ WxPython的跨平臺前端

基于Python+PySide/PyQt的跨平臺前端。