2020年第一屆低代碼研討會上， Jordi Cabot發表了一篇文章（或者說觀點），對比了低代碼和模型驅動開發的關系，認為低代碼等于模型驅動開發。但實際上，不少低代碼系統并不是使用模型驅動的，而是采用另一個策略，即代碼生成。那這兩者區別是什么，各有什么優勢， 本文會詳細介紹。
關于代碼生成和模型解釋
在模型驅動開發中，代碼生成用于從更高級別的模型生成代碼，以創建可運行的應用程序。讓我們考慮下面這個使用領域特定語言（Domain-Specific Language， DSL）創建的領域模型：
Customer { Name: String; Address: String;}
如果我們想為這個小模型生成Java代碼，我們可以使用模板引擎。模板包含Java代碼和一些Token，這些Token將根據模型來填充。例如，我們可以為域模型中的每個實體使用模板。模板代表一個Java類，實體的名稱作為類名（例如客戶）。對于每個屬性，將生成一個私有字段。
在模型解釋的情況下，我們不會通過生成代碼的方式來從模型中創建一個可運行軟件應用程序。在模型解釋中，我們會使用一個（比如）Java實現的通用引擎用，模型直接由這個引擎來解釋。例如，這個通用的Java程序中包含一個帶有屬性name的類Entity和一個包含該實體屬性（name-value對）的hashmap。在這種情況下，客戶實體不是由Java類表示的，而是由一個帶有屬性名稱的Entity對象表示的，該屬性name的值是Customer。這些實體對象是根據模型中的信息創建的。
代碼生成和模型解釋都在實踐中使用。讓我們來看看這些方法相互比較的優勢。
代碼生成的優勢
與模型解釋相比，代碼生成具有以下優點：
- 它保護你的知識產權：通過代碼生成，你可以為特定的客戶端生成一個應用程序。當使用模型解釋時，你必須給把整個運行時引擎給客戶，這樣才能實現整個應用。例如，如果要構建一個網站，你可以把運行網站所需的所有代碼給到客戶即可。而如果使用解釋器，你必須給他們整個系統來解釋任何可以用你的DSL描述的網絡應用。當您的產品有大量客戶的時候，這一點尤其重要。
- 它可以適應您的客戶架構：當使用模型解釋時，您必須按照自己選擇的架構實現解釋器。在代碼生成的情況下，您可以根據客戶的要求來生成代碼。
- 生成的實現更容易理解：您可以查看生成的代碼并直接理解應用程序的行為。在模型解釋的情況下，您必須理解解釋器的通用實現和模型的語義。
- 更容易上手：如果您已經手工構建了一個應用程序，您可以開始使用代碼生成，方法是將現有代碼轉換為模板，并用token替換部分代碼，token將被模型信息替換。如果您為同一個領域構建了多個應用程序（例如，為不同的客戶），您可以開始分析這些應用程序。靜態代碼（即所有應用程序的代碼都是相同的）可以放在域框架中，只需要生成可變代碼即可（即您需要創建域特定語言來建模可變性）。
- 它更容易迭代：正如前面所解釋的，您可以通過將現有代碼轉換為代碼生成模板來開始使用代碼生成。當然，您可以通過迭代的方式做到這一點。首先，您只生成代碼的一部分，其他部分將手動實現，稍后，您可以擴展代碼生成器以生成代碼的更多部分。您的DSL也是如此。起初，它可以是初級的，以反映將要生成的代碼。以后，您可以通過提高抽象級別來提升領域專業能力。
- 編譯器為它提供了的附加的檢查能力：當您生成代碼時，需要編譯該代碼。這個編譯步驟是一個附加的檢查，因為編譯器將檢查生成的代碼是否有錯誤。如果有解釋器，您需要在模型解釋期間自己進行這些檢查，或者您需要在建模環境和解釋器之間創建一個緊耦合。
- 調試生成器本身比調試解釋器更容易：如果您需要調試解釋器，則始終需要條件斷點，因為解釋器代碼是通用的。
- 模板的變化更容易跟蹤：代碼生成模板只是文本文件，因此變化很容易跟蹤（例如通過使用版本控制系統）。解釋器代碼的變化也是如此，但是，這段代碼是通用的，不容易搞清楚到底發生了什么變化。
模型解釋的優點
與代碼生成相比，模型解釋具有以下優點：
- 它支持快速變更：模型中的更改不需要再次代碼生成、編譯、測試和重新部署。這將縮短上線時間。
- 它支持在運行時進行更改：因為模型在運行時可用，所以甚至可以在不停止運行應用程序的情況下更改模型。
- 更容易移植：解釋器原則上創建一個獨立于平臺的目標來執行模型。創建一個運行在多個平臺（例如多個操作系統、多個云平臺）上的解釋器很容易。在代碼生成的情況下，您需要確保您生成的代碼符合平臺要求。在模型解釋的情況下，解釋器是一個黑匣子，只要它能在目標平臺上運行，如何實現并不重要。
- 更容易部署：當使用代碼生成時，您經常會看到您需要在Eclipse或Visual Studio中打開生成的代碼，并構建它來創建最終的應用程序。在模型解釋的情況下，您只需啟動解釋器并將模型放入其中。代碼不再是必要的了。因此，對領域專家來說， 部署和運行應用程序比僅僅建模要容易得多。
- 更容易升級和縮放：更改解釋器并用相同的模型重新啟動它更容易。您不必使用更新的生成器再次生成代碼。縮放也是如此：縮放應用程序意味著初始化解釋器的更多實例，執行相同的模型。尤其是在云環境中，這可以給你帶來優勢。
- 它更安全：例如，在云平臺上，你只需要上傳你的模型，就不需要訪問文件系統或其他系統資源。只有解釋器中的代碼可以訪問系統庫。解釋器在基礎設施之上提供了一個額外的層，下面的一切都被抽象掉了。這本質上是平臺即服務（PaaS）的想法。
- 它比代碼生成更靈活：基于模板的代碼生成是有限制的。在這種情況下，您將需要幫助文件來擴展基于模板的代碼生成的可能性。在這種情況下，解釋器可能不那么復雜，通常需要更少的代碼來完成相同的結果。
- 在運行時調試模型：雖然模型在運行時可用，但可以通過在運行時遍歷模型來調試模型（也就是說，您可以在模型上添加斷點）。這僅適用于操作語言，而不適用于聲明性語言（在那里您需要靜態分析）。當可以在模型級別調試時，域專家可以調試自己的模型，并根據此調試調整應用程序的功能行為。這在使用復雜的過程或狀態模型時非常有幫助。
結論
比較這兩種方法的優勢，我們可以得出結論，最終這完全取決于構建和/或使用模型驅動軟件工廠的人員的領域、用例和技能集（或舒適性）。
當我們討論代碼生成和模型解釋之間的區別時，很快就會帶來更多的問題：代碼生成和模型解釋之間有什么區別？這兩種方法之間的界限是什么？如果我們在生成代碼時有一個內存文件系統呢？如果我們通過編譯模型的一部分來優化我們的解釋器呢？如果解釋器為瀏覽器生成數據庫結構和網絡內容呢？
好了，今天的文章分享到這就結束了，要是喜歡的朋友，請點個關注哦！–我是簡搭(jabdp)，我為自己“帶鹽”，感謝大家關注。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
