作為一個(gè)寫代碼寫了十來年的老家伙我深知“數(shù)據(jù)庫反向生成實(shí)體”這幾個(gè)字的含金量。尤其是當(dāng)項(xiàng)目表數(shù)量動輒幾十上百張手寫實(shí)體類純屬給自己上刑。SmartDapper.UI 就是干這個(gè)的。它本質(zhì)上是一個(gè)可視化代碼生成器連上數(shù)據(jù)庫勾選表點(diǎn)幾下鼠標(biāo)一套整齊的實(shí)體類代碼就給你吐出來了。這篇文章我不會給你講那些虛頭巴腦的架構(gòu)就實(shí)打?qū)嵉夭鸾庖幌逻@個(gè)工具的設(shè)計(jì)邏輯、核心實(shí)現(xiàn)以及我在實(shí)際開發(fā)中踩過的那些坑希望能給正在折騰類似工具或者想提升開發(fā)效率的朋友一些參考。1. 做這個(gè)工具之前我每天都在跟實(shí)體類較勁1.1 手寫實(shí)體類的“三座大山”我相信大部分 .NET 開發(fā)者都有過這種經(jīng)歷數(shù)據(jù)庫設(shè)計(jì)文檔倒是挺全但真正要落地寫代碼的時(shí)候看著那幾十張表心里就開始發(fā)怵。第一座大山是重復(fù)勞動無非就是public int Id { get; set; }這種屬性定義一張表少說七八個(gè)字段多則二三十個(gè)全手敲下來手指頭都能磨出繭子。第二座大山是極易出錯(cuò)字段類型對應(yīng)錯(cuò)、可空標(biāo)記漏掉、字段名大小寫不規(guī)范這些問題在編譯期根本發(fā)現(xiàn)不了等程序跑起來報(bào) SqlException 的時(shí)候你再去一行行對數(shù)據(jù)庫結(jié)構(gòu)那種感覺很酸爽。第三座大山是維護(hù)困難數(shù)據(jù)庫結(jié)構(gòu)一變更實(shí)體類就得手動同步萬一忘了運(yùn)行時(shí)就是各種奇怪的映射錯(cuò)誤。我們當(dāng)時(shí)項(xiàng)目用的是 SmartDapper 這套輕量級 ORM 框架它本身很靈活SQL 執(zhí)行和控制力都很好但缺點(diǎn)也明顯就是實(shí)體類寫法比較規(guī)范比如字段名駝峰命名、可空類型必須標(biāo)注清晰否則映射就會出問題。團(tuán)隊(duì)里新來的同學(xué)經(jīng)常因?yàn)閷?shí)體類寫得不規(guī)范導(dǎo)致各種隱晦的 bug排查起來特別費(fèi)勁。1.2 SmartDapper 的定位與實(shí)體類的“規(guī)范枷鎖”SmartDapper 說白了就是一個(gè)介于原始 ADO.NET 和重量級 ORM比如 EF Core之間的東西。它不會幫你自動管理實(shí)體跟表的關(guān)系而是讓你自己寫 SQL然后通過自定義的映射規(guī)則把查詢結(jié)果動態(tài)綁定到實(shí)體對象上。這種方式自由度極高特別適合查詢邏輯復(fù)雜、需要精細(xì)控制 SQL 的團(tuán)隊(duì)。但也正因?yàn)檫@個(gè)“自由度”反向生成實(shí)體類的要求就變得異常嚴(yán)格。你得保證實(shí)體類名跟表名能對應(yīng)上屬性名跟字段名能對應(yīng)上類型必須完全匹配。比如數(shù)據(jù)庫里某個(gè)字段是decimal(18,2)你給映射成double查出來的金額可能就出現(xiàn)精度偏移了。再比如datetime2這種類型如果實(shí)體里用的是老舊的DateTime雖然大部分情況下能兼容但遇到邊界值就很容易踩坑。所以 SmartDapper.UI 這個(gè)工具核心任務(wù)不只是生成一堆{ get; set; }那么簡單它得深入理解數(shù)據(jù)庫的元數(shù)據(jù)結(jié)構(gòu)然后通過嚴(yán)謹(jǐn)?shù)囊?guī)則生成一套完全適配 SmartDapper 映射要求的實(shí)體代碼。這讓它天然區(qū)別于網(wǎng)上那種千篇一律的 T4 模板后者只能生成一個(gè)“能用”的殼而我們追求的是“好用”且有規(guī)范保障的實(shí)體層。1.3 為什么非要加個(gè) “UI” 界面有人可能會問命令行工具dotnet tool或者腳本不也能生成嗎加個(gè) UI 是不是有點(diǎn)多余其實(shí)不然。我們團(tuán)隊(duì)早期確實(shí)用過命令行版本的代碼生成器但很快發(fā)現(xiàn)了問題參數(shù)太多太抽象比如要手動指定連接字符串、命名空間、要排除哪些表一不小心記不住參數(shù)就會寫錯(cuò)。而且命令行工具是“黑盒”操作生成前看不到數(shù)據(jù)庫里的實(shí)際表結(jié)構(gòu)心里沒底。后來我們決定做一個(gè)帶界面的版本核心訴求就三個(gè)第一能實(shí)時(shí)看到數(shù)據(jù)庫里的表清單和字段預(yù)覽做到“所見即所得”第二所有配置選項(xiàng)都是勾選式的降低上手門檻新同學(xué)培訓(xùn)十分鐘就能用第三生成結(jié)果可以即時(shí)預(yù)覽不滿意直接調(diào)整規(guī)則重新生成。這個(gè)“可視化交互”的思路就是 SmartDapper.UI 與普通代碼生成器最大的區(qū)別。2. 核心設(shè)計(jì)思路反向生成這件事到底怎么落地2.1 從建連到出碼的完整鏈路先梳理一下 SmartDapper.UI 的核心工作流程這條鏈路是所有功能的骨架理清它你就明白這個(gè)工具在設(shè)計(jì)層面的取舍。第一步是連接數(shù)據(jù)庫。工具通過 ADO.NET 的標(biāo)準(zhǔn)連接方式支持 SQL Server、MySQL、PostgreSQL、Oracle 等主流數(shù)據(jù)庫。連接字符串不用手寫通過界面拆分成“服務(wù)器地址”“數(shù)據(jù)庫名”“賬號密碼”等獨(dú)立字段自動拼接。這樣做的好處是屏蔽了不同數(shù)據(jù)庫之間連接字符串寫法的差異。比如 SQL Server 要指定Data Source、Initial Catalog而 MySQL 則是Server、Database如果讓用戶自己填很容易因?yàn)楦袷絾栴}連接不上。第二步是讀取元數(shù)據(jù)。連接成功后工具會從數(shù)據(jù)庫的信息模式如 SQL Server 的INFORMATION_SCHEMA視圖MySQL 的information_schema.COLUMNS表PostgreSQL 的pg_catalog系列視圖中把所有表、視圖、字段、主鍵、外鍵、默認(rèn)值等信息抓取并緩存起來。這里有個(gè)細(xì)節(jié)不能直接 SELECT * 去讀表數(shù)據(jù)因?yàn)閿?shù)據(jù)可能很大而且我們只需要結(jié)構(gòu)不需要內(nèi)容。第三步是規(guī)則映射。讀取到的原始字段類型、名稱、可空性需要轉(zhuǎn)換成 C# 的類型、屬性名和特性標(biāo)注。這一步就是工具的核心邏輯涉及一套映射配置后面會詳細(xì)說。第四步是代碼生成?；谟成浣Y(jié)果使用模板引擎拼接出完整的實(shí)體類代碼。這里沒有用 T4因?yàn)?T4 的語法對非 Windows 環(huán)境不夠友好而且在 UI 程序里嵌入調(diào)用麻煩。我們用的是一個(gè)輕量級模板引擎幾乎就是把常見的代碼片段固化下來然后用模型數(shù)據(jù)去渲染。第五步是預(yù)覽與導(dǎo)出。生成結(jié)果先在 UI 右側(cè)的文本預(yù)覽區(qū)展示確認(rèn)沒問題后可以一鍵把所有文件輸出到指定目錄并且按文件夾分好類。2.2 類型映射表數(shù)據(jù)庫類型到 C# 類型的換算規(guī)則說到 “類型映射”這是整個(gè)反向生成的核心技術(shù)點(diǎn)。數(shù)據(jù)庫里的類型五花八門跟 C# 的類型并不是一一對應(yīng)的稍有不慎就會生成出運(yùn)行期才爆雷的代碼。我列一下 SmartDapper.UI 里實(shí)際采用的映射規(guī)則大家可以對照參考這部分算是我踩坑踩出來的經(jīng)驗(yàn)數(shù)據(jù)庫類型以SQL Server為例C# 類型可空性處理備注說明intintNullableint 若允許為空常規(guī)整型沒問題bigintlongNullablelong 若允許為空大整型別用 int 接會溢出smallintshortNullableshort 若允許為空小整型用 int 浪費(fèi)也不算錯(cuò)但規(guī)范起見用 shorttinyintbyteNullablebyte 若允許為空注意范圍是 0-255bitboolNullablebool 若允許為空數(shù)據(jù)庫布爾decimal/numericdecimalNullabledecimal 若允許為空強(qiáng)制用 decimal不能用 double/float精度會丟money/smallmoneydecimalNullabledecimal 若允許為空同上金額一律 decimalfloatdoubleNullabledouble 若允許為空數(shù)據(jù)庫 float 對應(yīng) C# doublerealfloatNullablefloat 若允許為空數(shù)據(jù)庫 real 對應(yīng) C# floatdateDateTimeNullableDateTime 若允許為空日期datetimeDateTimeNullableDateTime 若允許為空老式日期時(shí)間datetime2DateTimeNullableDateTime 若允許為空精度更高用 DateTime 也能存datetimeoffsetDateTimeOffsetNullableDateTimeOffset 若允許為空帶時(shí)區(qū)時(shí)間別用 DateTimetimeTimeSpanNullableTimeSpan 若允許為空時(shí)間段char/ncharstringstring 本身可空定長字符串varchar/nvarcharstringstring 本身可空變長字符串最常用text/ntextstringstring 本身可空長文本舊類型盡量提醒轉(zhuǎn) nvarchar(max)varbinary/imagebyte[]byte[] 本身可空二進(jìn)制uniqueidentifierGuidNullableGuid 若允許為空全局唯一標(biāo)識xmlstringstring 本身可空XML 也當(dāng)字符串處理省心這里特別注意幾點(diǎn)。第一如果數(shù)據(jù)庫字段允許為空值類型生成的實(shí)體屬性就要標(biāo)注為可空NullableT這不僅是為了避免賦值報(bào)錯(cuò)更是為了在 JSON 序列化和業(yè)務(wù)邏輯里明確傳達(dá)“可能沒值”的語義。第二decimal的精度和位數(shù)比如decimal(18,2)不能光生成一個(gè)decimal就完事最好在生成的特性如[Column(TypeNamedecimal(18,2))]里體現(xiàn)出來這樣在 EF Core 之類的場景里也能正確建表映射。SmartDapper 雖然不走 EF 那套但保留這個(gè)標(biāo)注絕對沒壞處。2.3 命名與規(guī)范處理表名轉(zhuǎn)類名字段名轉(zhuǎn)屬性名類型映射解決了“什么類型”的問題接下來就要解決“叫什么名字”的問題。數(shù)據(jù)庫里的表名和字段名習(xí)慣通常是PascalCase如UserInfo或者snake_case如user_info甚至有人用全大寫加下劃線USER_INFO。但 C# 編碼規(guī)范里類名和屬性名推薦用PascalCase我們必須有一套健全的轉(zhuǎn)換規(guī)則。SmartDapper.UI 的處理方式分幾步。第一步是分詞把表名按_、空格、駝峰邊界拆成單詞數(shù)組。比如product_order_detail會拆成[product, order, detail]ProductOrderDetail也會拆成同樣結(jié)果。第二步是規(guī)范化排除掉常見的無意義前綴比如某些團(tuán)隊(duì)習(xí)慣表名帶t_、tb_前綴字段名帶f_、col_前綴這塊做成可配置選項(xiàng)用戶根據(jù)自己公司規(guī)范決定去不去掉。第三步是拼接把處理后的單詞首字母大寫然后按PascalCase拼起來得到最終的類名或?qū)傩悦１热鏿roduct_order_detail最終生成ProductOrderDetail。但這里還有個(gè)細(xì)節(jié)容易踩坑就是字段名剛好是 C# 關(guān)鍵字的情況。比如數(shù)據(jù)庫里有個(gè)字段叫eventMySQL 很常見生成public string event { get; set; }必然編譯不過。工具的解決方案是自動追加一個(gè)前綴變成public string event { get; set; }這樣既保留了原始字段名又能通過編譯。此外還有字段名是date、string、object這類跟類型撞車的情況處理邏輯一樣。3. 實(shí)操之旅從連庫到出碼一步一步來3.1 第一步配置數(shù)據(jù)庫連接打開 SmartDapper.UI首先看到的就是數(shù)據(jù)庫連接配置面板。這地方?jīng)]什么花哨的就是填信息。但有一點(diǎn)比較人性化它內(nèi)置了常見數(shù)據(jù)庫的連接串模板。比如你選了 SQL Server下方會自動生成一個(gè)標(biāo)準(zhǔn)連接串占位符你只需要替換服務(wù)器名和數(shù)據(jù)庫名即可選 MySQL 時(shí)如果本地裝了驅(qū)動甚至支持只填Server、UserId、Password三件套自動補(bǔ)齊其余的默認(rèn)參數(shù)。連接信息填好以后務(wù)必點(diǎn)一下“測試連接”按鈕。我之前見過不少同事直接跳過測試點(diǎn)擊下一步結(jié)果彈出個(gè)數(shù)據(jù)庫不存在或者權(quán)限不足的報(bào)錯(cuò)又回頭改半天配置。這里我建議如果連接的是生產(chǎn)庫或共享開發(fā)庫盡量用只讀權(quán)限的賬號去連工具只讀結(jié)構(gòu)不需要增刪改的權(quán)限既安全又不影響他人。連接成功后左側(cè)列表會立刻顯示當(dāng)前庫中的所有表默認(rèn)過濾掉系統(tǒng)表。有的庫表特別多比如幾百張如果你清楚自己要哪些表可以直接在頂部搜索框輸入關(guān)鍵詞模糊過濾大大提升定位效率。3.2 第二步勾選需要生成的表并查看字段細(xì)節(jié)在表列表里每一行前邊都有一個(gè)復(fù)選框你可以勾選一張表也可以全選。勾選之后點(diǎn)擊該表名稱右側(cè)的字段預(yù)覽區(qū)會展示這張表的詳細(xì)結(jié)構(gòu)列名、數(shù)據(jù)類型、長度、精度、是否允許為空、是否為主鍵、默認(rèn)值、備注信息等。這個(gè)預(yù)覽區(qū)域非常有用它讓你在生成代碼之前就能直觀核對這張表到底有哪些字段類型長什么樣避免代碼生成完才發(fā)現(xiàn)字段不對。在字段預(yù)覽區(qū)下方還有一個(gè)“字段映射預(yù)覽”這個(gè)區(qū)域更高級。它不是顯示原始的數(shù)據(jù)庫字段信息而是實(shí)時(shí)顯示這張表經(jīng)過規(guī)則轉(zhuǎn)換后生成的 C# 屬性名、C# 類型、可空標(biāo)注、默認(rèn)值等。你可以在這里就檢查出問題。比如某個(gè)字段叫USER_NAME生成后屬性名是否符合你的預(yù)期如果不對可以去全局規(guī)則里調(diào)整。我實(shí)際操作時(shí)的建議是先別急著全選所有表建議先勾選 1 到 2 張比較有代表性的表比如包含各種數(shù)據(jù)類型、有主外鍵關(guān)系的表生成出來預(yù)覽一下看看整體效果是否符合團(tuán)隊(duì)規(guī)范。確認(rèn)沒問題后再全選所有表批量生成。不要一上來就梭哈否則生成的幾百個(gè)實(shí)體類里可能混雜著大量不符合要求的代碼后續(xù)返工更痛苦。3.3 第三步設(shè)置命名空間與生成選項(xiàng)生成代碼之前需要在右側(cè)配置面板里把參數(shù)填好。這一塊如果理解透徹能省很多事。第一個(gè)核心選項(xiàng)是“實(shí)體類命名空間”比如MyProject.Domain.Entities。后續(xù)生成的代碼里頂部的namespace就會用這個(gè)值。第二個(gè)是“是否生成特性標(biāo)注”。如果你打算同時(shí)使用 EF Core 這類需要特性標(biāo)注的框架或者想讓自己手寫的 SQL 映射器能識別表名映射建議勾上生成[Table(product_order_detail)]這類特性確保實(shí)體類名和真實(shí)表名之間沒有歧義。對于 SmartDapper 的使用場景即使不生成這個(gè)特性其實(shí)也能正常工作因?yàn)橛成湟?guī)則可以獨(dú)立配置但保留它能讓實(shí)體信息更完整自文檔化程度更高。第三個(gè)是“是否生成可空引用類型標(biāo)注NRT”。如果你的項(xiàng)目開啟了 .NET 的 Nullable 上下文Nullableenable/Nullable那么所有引用類型屬性都會自動加上?比如public string? Name { get; set; }。這能大幅降低空引用警告同時(shí)提醒調(diào)用者注意值可能為空。如果項(xiàng)目還沒啟用 NRT這塊建議先別勾不然生成的代碼可能編譯不通過。第四個(gè)是“是否包含數(shù)據(jù)庫備注”。勾選后工具會讀取字段的擴(kuò)展屬性作為 XML 注釋寫入實(shí)體類中比如/// summary 用戶姓名 /summary。強(qiáng)烈建議勾上注釋就是代碼的說明書后續(xù)維護(hù)的人包括三個(gè)月后的自己會感謝你這個(gè)決定。第五個(gè)是“只生成數(shù)據(jù)實(shí)體還是同時(shí)生成查詢對象”。我們后來發(fā)現(xiàn)日常開發(fā)中除了直接映射表的實(shí)體經(jīng)常還需要專門用來接收查詢結(jié)果的 DTO。SmartDapper.UI 的進(jìn)階功能就是支持生成一個(gè)“僅包含指定字段”的查詢 DTO 類這在復(fù)雜報(bào)表查詢里很實(shí)用但前提是要在表字段預(yù)覽區(qū)手動勾選需要的字段。默認(rèn)情況下這個(gè)功能是關(guān)閉的保證初學(xué)者的使用簡單。3.4 第四步批量生成與文件輸出配置都設(shè)置好后點(diǎn)擊“生成代碼”按鈕工具就會把前面讀取到的表結(jié)構(gòu)數(shù)據(jù)逐一送入模板引擎渲染出完整代碼。這個(gè)過程很快就完成了即使幾百張表也就是一眨眼的功夫。生成的代碼在右側(cè)預(yù)覽區(qū)默認(rèn)展示第一張表的實(shí)體類。預(yù)覽區(qū)下面有個(gè)“選擇查看其他實(shí)體”的下拉框可以快速切換查看不同表的生成結(jié)果。確認(rèn)一切無誤后點(diǎn)“導(dǎo)出到文件夾”選擇一個(gè)空目錄工具會按照“每個(gè)實(shí)體一個(gè) .cs 文件”的方式輸出文件命名跟類名保持一致。如果你的項(xiàng)目是按模塊分的文件夾還可以在導(dǎo)出時(shí)設(shè)置“子文件夾前綴”比如把跟order相關(guān)的實(shí)體批量放進(jìn)Orders子目錄這個(gè)功能在處理大型項(xiàng)目時(shí)尤其好用。文件導(dǎo)出后我建議你第一時(shí)間把整個(gè)目錄拖進(jìn) IDE 里編譯一遍看看有沒有生成錯(cuò)誤。雖然工具已經(jīng)內(nèi)置了很多防護(hù)措施但畢竟數(shù)據(jù)庫的類型是千奇百怪的總有一些你沒見過的情況可能導(dǎo)致模板渲染出錯(cuò)或者生成代碼不合規(guī)。編譯是最直接的驗(yàn)證手段。4. 問題排查與避坑手冊那些年我踩過的反向生成大坑4.1 最容易踩到的六類問題根據(jù)我的實(shí)際使用和給團(tuán)隊(duì)做內(nèi)訓(xùn)的經(jīng)歷用這類工具最容易踩的坑基本集中在下面幾類我整理成表格方便速查問題現(xiàn)象根本原因排查思路與解決方案生成的屬性類型跟數(shù)據(jù)庫對不上自定義類型、枚舉列、或者數(shù)據(jù)庫版本的差異導(dǎo)致工具無法識別打開字段映射預(yù)覽手動修正該字段的 C# 類型工具里支持“自定義類型映射字典”來解決不常見類型部分表在列表里看不到連接賬號的權(quán)限不足只能看到部分表或者工具默認(rèn)過濾了視圖檢查賬號權(quán)限在工具設(shè)置里打開“顯示視圖”選項(xiàng)生成代碼里字符串沒加?可空標(biāo)注丟失項(xiàng)目啟用了 NRT但生成選項(xiàng)沒勾選去生成選項(xiàng)勾選“生成可空引用類型標(biāo)注”重新生成表名或字段名帶特殊字符生成的代碼編譯報(bào)錯(cuò)名稱包含$、#、空格或者直接就是關(guān)鍵字工具會自動追加前綴或轉(zhuǎn)義字符但如果手動建表不規(guī)范需要先在數(shù)據(jù)庫端改掉名字decimal 字段生成后變成了 double映射規(guī)則里沒配置走了默認(rèn)值分支在類型映射配置頁里把所有decimal/numeric統(tǒng)一映射到decimal同一張表批量生成多次后代碼文件重復(fù)輸出目錄沒清空或生成時(shí)沒選“覆蓋模式”導(dǎo)出時(shí)選擇“清空目錄后導(dǎo)出”或確認(rèn)覆蓋選項(xiàng)避免文件堆積上面這些坑每一個(gè)我都親眼見過團(tuán)隊(duì)里的同事踩過而且?guī)最悊栴}還經(jīng)常交叉出現(xiàn)排查起來確實(shí)很費(fèi)精力。最有效的預(yù)防手段就是前面提到的先小范圍生成預(yù)覽確認(rèn)規(guī)范后再批量生成。4.2 實(shí)測案例同名字段在不同數(shù)據(jù)庫中的表現(xiàn)差異不得不說同一個(gè)工具連不同數(shù)據(jù)庫也會因?yàn)閿?shù)據(jù)庫本身的特性而出現(xiàn)一些意想不到的差異。舉個(gè)例子我們一個(gè)項(xiàng)目同時(shí)用了 SQL Server 和 PostgreSQL 兩套庫。SQL Server 里的uniqueidentifier類型生成的 Guid 屬性一點(diǎn)問題沒有。但 PostgreSQL 里對應(yīng)的類型叫uuid我們的類型映射里沒提前配置結(jié)果生成出來的屬性類型成了string雖然能用但總感覺不夠優(yōu)雅而且跟 SQL Server 那邊的實(shí)體類型不一致導(dǎo)致跨庫數(shù)據(jù)遷移時(shí)還需要特判。還有一個(gè)差異點(diǎn)是默認(rèn)值的處理。SQL Server 的表字段默認(rèn)值會在元數(shù)據(jù)里顯示為((getdate()))而 PostgreSQL 則是now()。如果我們直接把默認(rèn)值當(dāng)成常量生成到代碼里那肯定是不對的。這里工具做了“智能判斷”—— 檢測到getdate()、now()、CURRENT_TIMESTAMP這類函數(shù)默認(rèn)值就在生成的代碼里加一個(gè)DateTime.Now的屬性初始值而不是把函數(shù)體本身塞進(jìn)去。這個(gè)細(xì)節(jié)是我們在幾次版本迭代之后才打磨完善的做類似工具的朋友可以留意下這個(gè)點(diǎn)。4.3 版本迭代中的經(jīng)驗(yàn)沉淀開發(fā) SmartDapper.UI 的過程中我最大的體會是這類工具沒有完美的“一鍵生成”它永遠(yuǎn)需要跟著團(tuán)隊(duì)的編碼規(guī)范演進(jìn)。第一版只做了基礎(chǔ)的類型映射和命名轉(zhuǎn)換后來我們引入了 NRT馬上就發(fā)現(xiàn)需要適配可空標(biāo)注。再后來有的團(tuán)隊(duì)開始從 Dapper 遷移到 EF Core我們發(fā)現(xiàn)生成的實(shí)體類還需要加上主鍵特性[Key]。每次需求變化都意味著工具要加新的選項(xiàng)、新的規(guī)則。所以如果你們團(tuán)隊(duì)也想搞一個(gè)內(nèi)部的反向生成工具我的建議是不要一開始就追求功能大而全先把最基礎(chǔ)的“生成可用的實(shí)體類”這條鏈路跑通然后通過收集使用反饋不斷迭代。最重要的是把“規(guī)則”和“模板”做成可配置、可替換的否則改一個(gè)命名規(guī)范就得改核心代碼那后面會非常痛苦。SmartDapper.UI 的內(nèi)部設(shè)計(jì)中類型映射和命名規(guī)則都做成了獨(dú)立的規(guī)則引擎通過 JSON 配置就能調(diào)整這一點(diǎn)為后期維護(hù)省了太多力氣。我個(gè)人在實(shí)際使用中最喜歡的一個(gè)小功能是“生成前后差異對比”。因?yàn)槲业谋斫Y(jié)構(gòu)經(jīng)常微調(diào)字段加加減減如果重新生成整個(gè)實(shí)體類就等于把我手工改過的代碼也覆蓋了。后來工具加了一個(gè)“對比生成”功能它會把新生成的代碼和本地的舊文件做差異對比只把結(jié)構(gòu)變化的部分高亮顯示我就能精準(zhǔn)知道哪里變了再決定要不要手動改回去。這個(gè)小功能聽起來不起眼但確實(shí)能省掉很多次誤操作的恢復(fù)時(shí)間。最后再分享一個(gè)經(jīng)驗(yàn)代碼生成工具是提升效率的利器但它也是一把雙刃劍。它生成的代碼質(zhì)量完全取決于你給它配置的規(guī)則質(zhì)量。使用的時(shí)候一定要帶著“審查”的心態(tài)去看生成的代碼不要盲目相信工具的輸出。畢竟數(shù)據(jù)庫設(shè)計(jì)好不好字段命名規(guī)不規(guī)范這些底層的質(zhì)量問題工具沒法幫你解決。它只是幫你把“差勁的數(shù)據(jù)庫結(jié)構(gòu)”翻譯成“差勁的實(shí)體類代碼”的過程變得更快了而已。工具的價(jià)值在于自動化而好的實(shí)體類設(shè)計(jì)永遠(yuǎn)需要人來把控。