我們知道大部分低代碼平臺都采用了模型驅動的開發(fā)模式，即通過可視化建模的方式來實現(xiàn)軟件的設計和生成。領域模型創(chuàng)建完成后，有兩種技術路線來生成和運行模型應用：
- 方法一：對生成的模型進行編譯并生成所有相關的源代碼，使其成為普通的應用系統(tǒng)，該技術稱為“代碼生成”；
- 方法二：利用模型解析執(zhí)行引擎直接解析并運行所生成的模型，該技術稱為“模型解析”。
什么是模型驅動開發(fā)呢？其實這種架構設計在大型2B的企業(yè)項目中是比較常見的：
基于元數(shù)據(jù)建模思路
所謂軟件系統(tǒng)設計，核心是對現(xiàn)實的對象進行數(shù)字化，如果采用一對一映射建表的“硬建模”，業(yè)務對象間的關系分散在各個存儲表中，業(yè)務對象的新增和變化都會對數(shù)據(jù)表造成影響，業(yè)務對象關系的新增和變化都會對數(shù)據(jù)表的Schema造成影響。
這里有一張在電信機房的配線架圖片，我們分別用“硬建?！焙汀按箢愒獢?shù)據(jù)建模”思路來分析兩種建模方式的差別。
電信機房配線架
“硬建?！狈桨?/strong>，我們設計了一個配線架管理的物理模型表（藍色部分），隨著硬件工藝升級，我們的配線架升級為雙面配線架，這個時候我們需要增加一個新的模型：操作面（黃色部分）。我們發(fā)現(xiàn)這次需求升級，模型改動涉及面很大，增加了三個關系，和操作面相關的模型都需要進行調整，影響了四個模型實體。
硬建模方案
這次改動帶來的生產(chǎn)影響是什么呢？
- 數(shù)據(jù)庫層面新增1個表、改動3個表
- 應用層面新增1個對象、改動3個對象，新增3個操作函數(shù)
- 必須要停止數(shù)據(jù)庫來進行改動操作
采用“硬建?！痹O計的架構簡單可讀，項目維護簡單，但是一旦需求升級變化，30%的代碼都需要進行調整，那么相關的測試、實施投入都相對較大。
“大類元數(shù)據(jù)建?！狈桨?/strong>，我們定義了一個“硬件”大類模型，硬件具備包含、容納關系能力。針對雙面配線架需求，我們的改動僅僅是在元數(shù)據(jù)中增加了一個“操作面”的定義，如果“操作面”的的屬性沒超過“硬件”屬性范圍，我們都不需要增加物理表。如果操作面有特殊屬性，我們只需要在物理庫增加一張擴展表，而業(yè)務關系和核心屬性都在主表“硬件”上進行管理，相關的業(yè)務代碼也無需調整，系統(tǒng)也無需停機。
基于大類元數(shù)據(jù)建模
我們歸納下大類元數(shù)據(jù)建模思路如下：
- 保持大類業(yè)務實體和關系實體的穩(wěn)定，關系全部體現(xiàn)在大類上；
- 細類繼承大類業(yè)務實體和關系實體，以擴展表方式實現(xiàn)靈活擴展；
- 通過元數(shù)據(jù)配置驅動，實現(xiàn)模型快速、在線擴展；
大類元數(shù)據(jù)建模思路
這里我們講解的大類元數(shù)據(jù)模型是一種軟件架構設計方法，也是低代碼軟件架構設計方法：既穩(wěn)定又易用
平衡的架構設計
穩(wěn)定性
越抽象越穩(wěn)定。E-R是所有MIS數(shù)據(jù)模型的起源，可以描述世界上任何東西，最穩(wěn)定。但越抽象，則意味著越多的工作丟需要應用來完成，且不易為程序員和用戶理解。
易用性
越貼近現(xiàn)實越容易使用。對現(xiàn)實實體一對一的“硬建模”最容易理解和使用。但建模越“硬”，則意味著停機改動數(shù)據(jù)模型的可能性越大，越容易對生產(chǎn)造成負面影響。
實用性
實用性取決于應用需要什么抽象度的管理對象。包括：管理對象的粒度——實體（E）和管理對象的功能——關系（R），我們架構設計的過程需要從E-R出發(fā)，細分實體和關系概念，直到滿足各應用的管理要求為止。
版權聲明：本文內容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。
