使用代碼生成工具快速開發ABP框架項目

在通常系統開發中，咱們通常要藉助於高度定製化的代碼生成工具，用於統一代碼風，節省開發時間，提升開發效率。不一樣的項目，它的項目不一樣分層的基類定義不一樣，咱們須要在框架基類的基礎上擴展咱們的業務類代碼，儘可能根據已有數據庫設計的信息，完整、詳細的重現咱們須要的編碼工做，一方面引入必要的關係和代碼，一方面保留必定的註釋代碼供瞭解使用，站在開發者的角度上思考代碼如何編寫，這樣纔可以快速、高效的增量化開發咱們的業務表應用模塊。

一、數據庫的設計

通常狀況下，咱們每每喜歡基於數據庫建模咱們的業務表存儲內容，數據庫表是一切業務的核心，熟練的開發人員，每每都可以迅速根據需求的內容，以及框架所需的信息，準確的定義好所須要的表字段，包括界面展現的字段，以及後臺必備的一些關鍵字段，如建立日期，建立人、所屬部門等等。

咱們通常推薦使用第三方的建模工具，如PowerDesigner工具來進行數據庫表的建模，這樣能夠方便分享和修改，能夠根據須要隨時調整生成的數據庫腳本。

數據庫表通常須要添加備註信息，做爲生成實體類字段的備註，或者錄入界面的文本標籤等等，咱們框架使用代碼生成工具生成代碼的時候，儘量的多利用備註信息，用來標識或者說明類或者字段的信息。

準確而明瞭的備註信息，能夠下降咱們介入代碼備註說明信息的有效手段。

 

二、框架的多數據庫支持

對於多數據庫的支持，通常是框架底層須要考慮的，好的框架每每很容易支持多種數據庫的切換處理的。

在開發不一樣框架的系統應用的時候，咱們每每以其中一個數據庫系統爲藍本，先開發完成，而後再行擴展其餘數據庫的支持便可。

例如對於混合框架中，底層主要使用微軟企業庫實現多種數據庫的切換的，它的底層是經過擴展適配來實現的。

而對於ABP框架來講，它提供EFCore的數據庫抽象，所以也是支持多種數據庫的處理。

ABP默認的數據庫是SQLServer，不過ABP框架底層是EF框架，所以也是很容易支持其餘類型的數據庫的，如切換到Mysql操做，引入不一樣的包處理，而後調整下代碼便可。

ABP官方文檔中推薦使用的Mysql處理包，以下所示。

pomelo.entityframeworkcore.mysql

pomelo.entityframeworkcore.mysql.design

修改其中對應的常數定義，切換爲咱們所須要的Mysql數據庫便可，以下所示。

不一樣的數據庫支持，EFCore的切換代碼，主要是在EntityFrameworkCore項目的類MyProjectDbContextConfigurer下面。

    /// <summary>
    /// 配置使用特定數據庫的處理
    /// </summary>
    public static class MyProjectDbContextConfigurer
    {
        public static void Configure(DbContextOptionsBuilder<MyProjectDbContext> builder, string connectionString)
        {
            builder.UseSqlServer(connectionString);//默認SQlServer
            //builder.UseMySql(connectionString, new MySqlServerVersion(new Version(5, 7)));//MySQL

            //builder.UseNpgsql(connectionString);//PostgreSQL
            //builder.UseOracle(connectionString);//Oracle
        }

        public static void Configure(DbContextOptionsBuilder<MyProjectDbContext> builder, DbConnection connection)
        {
            builder.UseSqlServer(connection);//默認SQlServer
            //builder.UseMySql(connection, new MySqlServerVersion(new Version(5, 7)));//MySQL

            //builder.UseNpgsql(connection);//PostgreSQL
            //builder.UseOracle(connection);//Oracle
        }
    }

對於默認從SQLServer切換到Mysql的處理，詳細能夠參考隨筆《ABP框架使用Mysql數據庫，以及基於SQLServer建立Mysql數據庫的架構和數據》

若是須要支持Oracle數據庫，那麼也須要引入Oracle的以下驅動便可，以下所示。

 

 而後調整下MyProjectDbContextConfigurer類的代碼便可。

 

三、框架後端代碼生成

 通常來講，咱們基於框架的構建，基本上把通用的接口或者邏輯儘量都封裝在基類或接口裏面，以便減小咱們須要維護的代碼，基類代碼越抽象、統一，那麼所須要的開發工做量就會很是少，只須要擴展咱們本身的業務接口或函數便可，這方面也能夠經過調用公用的處理方法，來進一步下降代碼量。

ABP初始框架的各個分層的信息，它主要是分爲下面幾個項目分層。

Application應用層：應用層提供一些應用服務（Application Services）方法供展示層調用。一個應用服務方法接收一個DTO(數據傳輸對象)做爲輸入參數，使用這個輸入參數執行特定的領域層操做，並根據須要可返回另外一個DTO。

Core領域核心層，領域層就是業務層，是一個項目的核心，全部業務規則都應該在領域層實現。這個項目裏面，除了定義所需的領域實體類外，其實能夠定義咱們本身的自定義的倉儲對象（相似DAL/IDAL），以及定義本身的業務邏輯層（相似BLL/IBLL），以及基於AutoMapper映射規則等內容。

EntityFrameworkCore 實體框架核心層，這個項目不須要修改太多內容，只須要在DbContext裏面加入對應領域對象的倉儲對象便可。

Migrator數據遷移層，這個是一個輔助建立的控制檯程序項目，若是基於DB First，咱們能夠利用它來建立咱們項目的初始化數據庫。

Web.Core Web核心層，基於Web或者Web API的核心層，提供了對身份登錄驗證的基礎處理，沒有其餘內容。

Web.Core.Host Web API的宿主層，也是動態發佈Web API的核心內容，另外在Web API裏面整合了Swagger，使得咱們能夠方便對Web API的接口進行調試。

Tests 單元測試層，這個提供了一些應用層對象的模擬測試，其中測試的數據庫使用的是Entity Framework 的內存數據庫，不影響實際數據庫內容。

通過我進行簡化和優化處理的框架項目結構以下所示。

 以字典模塊爲介紹的話。

例如對於01-Core模塊層，須要增長文件

對於03-Application.Common模塊來講，須要增長DTO和應用服務層接口文件

而對於04-Application應用層來講，須要增長對應的接口實現文件

而0五、0六、07模塊，咱們不須要加入任何文件，08-Caller層加入對WebAPI的遠程調用封裝類，給Winform、WPF/UWP、控制檯程序等調用。

經過整合相關的生成規則，咱們能夠增長對應的ABP框架代碼的生成，以下代碼生成工具界面所示。

代碼生成工具Database2Sharp地址：http://www.iqidi.com/database2sharp.htm

最終根據根據選擇數據庫表信息，一鍵生成相關ABP架構分層代碼，文件結構以下所示。

 咱們只須要把這些生成的文件，增量式的合併到咱們的項目中便可完成後臺代碼的整合了。

因爲咱們發佈了ApplicationService層的類，那麼在Swagger的接口裏面，能夠查看咱們新增的業務接口了，已經具有了常規標準的增刪改查等接口了

ABP+Swagger負責API接口的發佈展現管理，以下是API接口的管理界面。

待咱們熟練各個業務接口的處理邏輯後，咱們就能夠進行手工的增長，或者調整邏輯了。

 

四、ABP框架Winform界面代碼的生成

 ABP框架的界面包含兩個部分，一個是Winform界面部分，這個和咱們常規的Winform開發框架或者混合框架界面開發差很少，根據數據庫表結構生成對應的列表展現和編輯界面，其中整合了條件查詢、分頁、導入、導出、查看、新增、編輯、刪除等操做功能。

Database2Sharp關於ABP框架的Winform界面配置。

設置好後直接生成，代碼工具就能夠依照模板來生成所須要的WInform列表界面和編輯界面的內容了，以下是生成的界面代碼。

放到VS項目裏面，就看到對應的窗體界面效果了。

生成界面後，進行必定的佈局調整就能夠實際用於生產環境了，省卻了不少時間。

在應用業務的模塊界面生成好並整合到解決方案後，就須要在後臺權限管理系統的菜單管理模塊中維護對應的入口，添加對應的菜單/工具欄入口了。

菜單資源管理的列表界面界面以下所示

雙擊樹列表或者右側的列表，均可以對已有的菜單進行編輯，菜單編輯界面以下所示。

主體框架界面採用的是基於菜單的動態生成，以及多文檔的界面佈局，具備很是好的美觀性和易用性。

 

五、ABP框架Element前端界面生成

Vue+Element的前端界面，是一套BS的純前端管理界面，它利用後端ABP提供的API接口做爲數據源，展現界面。

 引入了先後端分離的Vue + Element 做爲前端技術路線，那麼先後端的邊界則很是清晰，前端能夠在經過網絡獲取對應的JSON就能夠構建前端的應用了。

主體框架界面採用的是基於後臺配置的菜單動態生成，左側是菜單，右邊頂部是特定導航條和內容區。

 菜單能夠進一步展開更多內容，包括系統的權限模塊（機構、用戶、角色、菜單、功能），日誌，字典等等模塊內容，以及其餘展現案例模塊。

 咱們通常作增量開發，只須要完成ABP後臺代碼開發並整合後，使用代碼開發工具進一步開發Element前端界面便可，增量開發好對應業務模塊內容後整合在Vue&Element的前端框架中，並配置好菜單入口便可展現使用。

在代碼生成工具Database2Sharp界面裏面，選擇【代碼生成】【ABP的Vue+Element界面代碼】，以下所示。

按照代碼工具一步步選定表進行生成，在最後根據須要選擇不一樣的配置生成便可。

 或者選擇帶有樹列表的界面，並自定義指定目錄位置。  

 

 確認生成代碼後，咱們能夠看到對應的API調用JS類和Vue視圖文件，以下所示。

 

  咱們把這些整合到咱們的Vue&Element前端系統項目中。

而後在路由系統中加入對應的路由信息，路由信息是決定菜單是否可以訪問的關鍵，只有在路由列表集合裏面，菜單才放行的，以下所示。

在ABP + Vue + Element 快速開發框架裏面，咱們BS前端的菜單和其CS的菜單是各自分開的，咱們在後臺的權限模塊系統中維護菜單內容並分配給對應角色用戶，在用戶登陸系統後，動態加載菜單展現，並經過菜單的配置信息，跳轉到對應的路由上去進行頁面展現處理。

菜單資源管理的列表界面界面以下所示

這樣就完成了整個ABP框架，後端和前端的整合處理了。