低代碼技術與市場（Mendix與 OutSystems）
本文主要參考文章
參考鏈接
https://mp.weixin.qq.com/s/OXCBORheAx99o3fS-ZfUdg
https://blog.csdn.net/qq_38352351/article/details/110160054
低代碼分析
低代碼和無代碼（稱零代碼）是什么關系、怎么判斷一個低代碼平臺是否專業、國內是否有專業的低代碼平臺、低代碼是不是新瓶裝舊酒、低代碼真的搞不定專業的企業應用嗎、低代碼不適合開發哪些應用、低代碼并非銀彈。
01
低代碼和無代碼是兩回事
第一步得把低代碼和無代碼分清楚，因為這倆差異巨大，但現在業界經常混為一談，導致很多很多問題，比如雙方爭論但指的不是同一個事情，廠商的口徑亂，行業報告的結果不能看。
低代碼專指低代碼應用開發平臺（LCAP），是一個被業界廣泛認可的概念，頭部的分析機構如Forrester和Gartner都已經發布了多年低代碼開發平臺的報告。如下圖所示，大家可以看到這兩家的報告入選的產品都很接近，特別是頭部的六家簡直是一模一樣。這說明低代碼應用開發平臺已經是一個比較成熟的市場。

相反，分析機構對無代碼的態度就很微妙了。雖然有一些分析機構提無代碼開發平臺的概念，如G2（當然更不用說目前混亂的國內分析機構），但Forrester和Gartner從未發布過無代碼開發平臺的報告。Forrester和Gartner不是說無代碼是個偽概念，共識是無代碼這個詞只是一個營銷用語，主要用來突出一個工具無需編程基礎，消除業務用戶的恐懼。
無代碼這個詞通常用來形容一些細分領域的開發工具，最常見的是應用搭建平臺（國外一般叫App Builder之類），如國外的Appy Pie、國內的宜搭、簡道云等，可以形容Airtable / AppSheet / Treelab這類在線表單工具或輕流這類的工作流工具。這幾類工具差別巨大，如下圖所示，有人將無代碼和低代碼的江湖分成十二個“門派”，無代碼是一個相當寬泛的概念。

但無代碼的“通用”開發平臺，不會存在。因為開發軟件必然要編寫邏輯，就必然要寫代碼，除非哪一天人工智能能做到自動寫代碼。
低代碼和無代碼的關系有點類似于關系數據庫和NoSQL。關系數據庫專指一種特定的數據庫，即便多家廠商的產品實現可能千差萬別，但至少提供的功能很相似，都高度遵循SQL標準。低代碼開發平臺雖然今天的標準化程度還沒關系數據庫這么高，但無論是Gartner還是Forrester都已經開始給出比較清晰的篩選標準，如要支持通用場景（如UI、邏輯和數據三層都要有）、要滿足專業開發需求等，隨著行業發展標準化程度肯定會進一步提高。NoSQL只要不是SQL都算，不管是KV、wide-column、文檔還是圖，都可以叫NoSQL。NoSQL這個詞熱了有幾年，但現在不太講了，因為市場格局開始清晰之后，大家就不會關注過于寬泛的NoSQL，根據需要關注具體的類型。無代碼這個詞會慢慢淡出，雖然現在十二個門派很是熱鬧，但不出幾年真正有影響力的門派肯定不多，這時大家就不關注無代碼直接找具體的產品了。
低代碼不是一個想吸引業務用戶的用語，業務人員見了“代碼”兩個字就嚇跑了，再低沒用，如果業務人員寫不了100行代碼的話，10行一樣寫不了。低代碼平臺主要面向專業開發，這點已經是頭部分析機構的共識，雖然Forrester之前走過彎路，曾經發布過面向業務人員的低代碼開發平臺報告，但近兩年已經不再發布了，只保留面向專業開發者的低代碼報告。用戶數據說明這一點，21CTO在《低代碼開發可不低，用戶仍需要與IT技術部門聯手》一文中提到據某統計“只有6%的低代碼開發是由業務人員完成的”，OutSystems的數據是69%的用戶是專業開發，宜創科技CEO宜博曾說低代碼面臨“懂技術的看不上，懂業務的學不會”的尷尬。
所以無代碼和低代碼完全不同，無代碼面向業務人員，低代碼面向開發人員；無代碼泛指多種開發細分領域應用的工具，低代碼特指一種通用開發工具；無代碼不被國際頭部分析機構認可，低代碼被廣泛認可。
現在國內很多行業專家和分析機構經常把兩者混為一談，這對技術的價值衡量、甲方的技術規劃和選型都造成很大混亂，迫切希望大家能夠把低代碼和無代碼區分開，集中研究具備通用能力的低代碼平臺。
02
專業的低代碼長啥樣
現在市場上魚龍混雜號稱“低代碼”的產品很多，怎么才能快速區分是不是“專業”？很簡單，找一個最專業的產品對標。
哪個產品才是最專業的？可以先看為什么低代碼這兩三年才熱起來？不是因為Salesforce這樣的SaaS廠商，不是Appian這類BPMS廠商，這輪低代碼熱其實主要是因為OutSystems。OutSystems雖然早在2001年就成立，但之前一直“猥瑣發育”，2018年D融資了$3.6億，才突然引爆市場。無論Forrester還是Gartner都把OutSystems列入領導者象限，最推崇的低代碼平臺就四個，OutSystems是其中之一。所以，OutSystems就是專業低代碼平臺的代表。
對比OutSystems和很多國內所謂的低代碼平臺，找出了六項區分度最高的判斷標準：模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言。
（1）模型驅動
“模型驅動”可能是最明顯的區分標志，因為剛好有一個很流行的概念叫“表單驅動”。很多人搞不清楚這兩個概念，但其實這兩類產品挺好區分。
首先可以看用戶手冊，不用安裝試用能看出差別。使用模型驅動的平臺比如OutSystems、Mendix的手冊會有很大一章講怎么做數據建模和處理，包括怎么定義實體、實體間關系、主鍵、唯一性、索引、數據怎么訪問、篩選、分組、統計等等，還提供SQL或類似擴展。使用表單驅動的產品則往往手冊第一章就是說明怎么定義各種表單，都是各種和界面相關的控件，比如單選多選下拉框、文本日期數字等。

其次可以看界面。下圖是分別是模型驅動的OutSystems和某表單驅動產品的相關操作界面，是不是很不一樣。

（模型驅動，OutSystems）

（表單驅動）
（2）可視化開發
可視化開發不是拖拉拽做個界面（這只能叫可視化設計），有完整的可視化編程語言系統，能夠編寫業務處理邏輯。看OutSystems類產品的文檔，會發現很多編程語言的基本構造都有，比如順序 / 分支 / 循環 / continue / break、輸入輸出參數、局部變量 / 全局變量、struct和list、異常等。雖然這些東西都是拖拉拽完成，沒有密密麻麻的一行行代碼來嚇人，但足以嚇退業務人員。一下幾張圖都來自于OutSystems，大家可以感受一下。

（左：邏輯開發工具箱，注意有If、Switch、For Each流程控制；右：一個比較簡單的邏輯）

（怎么拋出和處理異常）
（3）表達式語言
表達式語言有些類似Excel里的公式，有表達式語言才可以做一些比較復雜的計算。下圖是OutSystems的表達式編輯器，有各種操作符，有很多內置函數，比如數學函數、字符串處理函數等。
OutSystems這個例子看起來比較簡單，但表達式語言可以很復雜。微軟是搞語言的行家，下圖是個微軟Power Fx的例子，這個表達式是要提取一個句子最后一個單詞的表達式，挺復雜吧（說實話看了好大一陣子才看懂）。

表達式語言有更平易近人的設計，比如輕舟就是用類似Scratch的積木塊設計。兩種設計功能上是等價的，積木塊設計更容易上手，Power Fx這樣的設計寫復雜表達式更方便。
（4）軟件工程
專業的低代碼平臺需要提供測試、debug、版本控制等軟件工程支持。開發軟件都會出bug（低代碼平臺基本消除了語法層面的bug，但對語義層面的bug一樣無能為力），需求總是會變。所以測試、debug、版本控制這些支持是必不可少的。OutSystems為什么做的最好，跟完善的debug支持是分不開的。下圖是OutSystems的debug界面，看起來和專業IDE有的一拼。

（5）開放集成
理論上，有了模型驅動等上述四大功能，開發一個不是太復雜的獨立應用就夠了，但典型的企業軟件都是相互依賴和集成的，所以平臺還需要具備能夠調用外部API和開放API給別人的能力。平臺如果沒有這兩方面的功能，開發出來的應用相互之間都沒法連通和集成，全是技術債。看國外關于低代碼的文章，經常會看到一個詞叫Shadow IT，說的就是這個問題。大家都胡亂的開發各種應用，都集成不起來，將是一場大災難。
（6）腳本語言
腳本語言就是用JavaScripts、Python、Java等做擴展，這些其實就是正兒八經的專業編程語言了，但低代碼平臺會把工程復雜性都封裝好，讓開發者不需要配置部署環境，隨手就可以寫代碼，寫完一鍵發布馬上可以運行。
其實上述標準和Gartner是很一致的。Gartner在魔力象限報告里說：
An LCAP is characterized by its use of model-driven or visual development paradigms supported by expression languages and possibly scripting…
里面模型驅動、可視化開發、表達式語言、腳本語言都提到了。
小結一下，判斷是不是"專業”低代碼，可以重點看模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言等六個方面。
03
國內有專業的低代碼平臺嗎
國內看似已經有很多低代碼平臺，道一云之前做個一個系列測評，T研究、海比等都出過分析報告，但只要對照上述標準就不難看出，雖然低代碼輿論很是喧囂，但迄今為止國內還很少有專業的低代碼平臺。
比如阿里今年一直鼓吹的宜搭，宣稱是“低代碼”應用搭建平臺，但其實是一個“表單驅動”的“無代碼”平臺。阿里其實是打了個擦邊球，說宜搭是“搭建”平臺，沒說是“開發”平臺，要說過度宣傳算不上。但“搭建”和“開發”二字之差，差距可大了，“搭建”的意思是基于一些成熟模塊組裝應用，一旦遇到既有模塊不夠用的時候就完蛋。
國內很多分析報告提及的產品大部分都瞄過，就ClickPaaS可能還夠得上（不確定，因為ClickPaaS不開放用戶手冊，沒深入研究），畢竟有模型驅動和開放集成，其他門檻都夠不上。
這么混亂的狀態讓CIO們可怎么辦呢，這再次說明如果缺乏有效的標準篩選真正專業的低代碼平臺，勢必低代碼和無代碼一鍋粥，結果大家都被搞得稀里糊涂。
04
低代碼真的是新瓶裝舊酒嗎
關于低代碼還有一種流行的觀點是新瓶裝舊酒，說二十年多年前的Delphi、PowerBuiler（后稱PB）早就是低代碼，但早就被時代淘汰了，今天的低代碼沒戲。說這些話的大概率還是前輩。
要講清楚這些問題得稍微digg一點歷史，當年的Delphi和PB可是神一般的存在，因為相比同時代的其他技術（比如MFC），易用性好太多，這倆不知道做了不知道多少企業信息化應用。隨手翻看一本《Delphi開發典型模塊大全》，里面盡是板材排料、進銷存、文檔管理、批發零售、房地產信息管理等案例。
這倆后來被時代淘汰，主要是因為時代變了，沒跟上。互聯網時代來了后，軟件架構很快就從桌面端的C / S變成Web端的B / S，再后來是移動App。Web應用和App對前后端的要求比桌面應用都要高很多，因為大家做網頁或App都是要勾引用戶主動訪問，不像桌面端的企業應用就算不好用為了工作得用。互聯網的這個二十年，技術棧發展的越來越復雜，新的低代碼技術只能一直慢慢醞釀。
但經過OutSystems等廠商經過十多年的積累，今天的低代碼技術已經遠勝當年的Delphi和PB。今天的低代碼要“低”的多，當年的Delph、PB等如果按今天的標準，連入門的資格都沒有。
就以當年最流行的Delphi為例，Delphi雖然號稱“可視化編程語言”，但就是實現了界面的可視化開發和數據庫的ORM，所有的邏輯都是要用代碼寫的，包括怎么把數據顯示在表格都要寫代碼。六大標準里，頭兩位的模型驅動、可視化開發這些都沒有。PB就比Delphi稍好一點，核心的DataWindow可以無需代碼做出增刪改查，算是邁入模型驅動的門檻，但不支持實體關系，模型驅動能力并不完整。同時PowerBuilder沒有可視化的邏輯開發，按今天的標準只能在門檻徘徊。
貼兩張老圖讓大家感受一下當年炸子雞—Delphi。

（Delphi的主界面，實現了用戶界面的可視化設計）

（Delphi的邏輯實現界面，得寫代碼）
今天的低代碼并不是新瓶裝舊酒，而是新瓶新酒，里外都是新的。說新瓶是因為低代碼這個概念是新的，說新酒是因為今日的OutSystems等專業低代碼產品的能力已經遠超二十年前PC時代的Delphi和PB。
05
低代碼能開發復雜的企業應用嗎
目前業界很多人認為低代碼搞不定復雜的企業應用。如ERP老兵果總在《低代碼，不要以比“中臺”還快的速度臭大街》一文中認為低代碼只適合用來做“簡單的工作流和表單流轉的應用”或“大型應用軟件的功能延伸的開發”，認為“不適合開發復雜邏輯的核心業務”。果總并沒有說為什么。“技術領導力”在《如何用低代碼搞垮一家公司？》一文中認為低代碼只適合“創新探索類”、“生命周期短的”等應用。同樣，沒有給出依據。類似的言論還很多，但都有一個共性，就是只說低代碼不行，不解釋，很多時候還把話說的那個斬釘截鐵。
企業應用聽起來高大上，但其實幾十年東西了，能有多復雜呢？界面不用很時尚，不用扛百萬并發，沒智能推薦啥的高級算法，其實從軟件開發角度看企業應用是比較簡單的。企業應用的復雜主要是領域模型和業務流程比較復雜，但低代碼平臺在建模和邏輯方面的能力都是比較全面的，再通過腳本語言、開放集成等擴展機制，對于不方便低代碼實現的地方，可以和專業代碼開發協作實現。所以用低代碼開發復雜應用，本質上沒問題。
明道云CEO任向暉寫過一篇《APaaS搞不定復雜的應用，是這樣嗎？》，把企業應用的復雜性分解為數據、權限、流程、算法、集成、報表等六個維度，然后逐一給出解決方案。這才是實事求是的態度。
用低代碼平臺開發這類應用，還有不少獨特優勢，如開發人員上手快（經驗是個把月就能用的很溜了），開發效率高，便于業務人員和開發之間的溝通（因為邏輯大多是可視化的），不容易形成孤島（因為專業的低代碼平臺默認就會根據模型生成API）。OutSystems在其網站上特意強調：
OutSystems is well-equipped to build ERP and similar large, complex systems with the desired performance and scalability.
OutSystems有一些這方面的案例，做供應鏈、CRM、ERP的都有。OutSystems成立于2001年，那時候不開發企業應用開發什么呢？
但可能很多人會說，OutSystems作為廠商當然這么宣揚，但目前用低代碼開發復雜企業應用確實不多。但認為這只是時間問題。
首先，低代碼技術達到成熟狀態的時間并不長，即便是OutSystems。OutSystems雖然都成立20年了，但低代碼表面看似簡單，其實是一個相當復雜的技術體系，背后涉及核心的編程語言層面的設計，比如DSL、類型系統、泛型等等，還有怎么diff、debug、undo，都不容易。另外低代碼平臺還需要不斷追趕這20年變化極大的技術環境。20年前是C / S、.Net，后來流行B / S、Java，再后來又得搞App，操作系統從Windows變成Linux，現在又面臨從SOA到微服務的轉型。OutSystems的主任工程師Tiago Sim?es曾介紹過20年來OutSystems的發展，可以看到OutSystems一邊一直到補功能，直到2014年的9.0版本支持數據聚合處理才算比較完整，另一邊一直在努力追趕技術趨勢，直到2016年的10.0版本一口氣推出Client-Side Logic、Local Storage、異步、Reactive等功能才算對移動App有較好的支持。這玩意是不做不知道，一做嚇一跳，是做了輕舟低代碼才知道這個東西很難。
更重要的可能是非技術因素。大部分企業對CRM、ERP的定制需求還沒那么高，相比用低代碼從頭開發來說，采用Saleforce、SAP這樣的套裝軟件實施，再做一些二次開發是更合適的選擇。這解釋了為什么Saleforce、ServiceNow這樣的SaaS巨頭都有自己的低代碼平臺，西門子會收購Mendix。另外ERP這樣的企業軟件實施強依賴咨詢經驗，這不是低代碼能解決的，業界有經驗的咨詢顧問顯然更熟悉SAP這樣的產品，沒有意愿改變。專業程序員對低代碼抵觸非常大，好不容易練就一身武藝，用了低代碼好像都沒用了？業界越是宣傳用低代碼開發快多少倍，開發團隊可能越抵觸。
總之，業界流行說低代碼不能做CRM、ERP這類復雜的企業應用，這一說法很多人講，但都沒有根據。從技術原理出發，低代碼最適合做的恰恰就是企業應用。目前用低代碼做復雜企業級應用的case還不是很多，是因為低代碼技術就剛成熟不久、定制需求還不夠強（套裝軟件能滿足）或者行業不愿做，并不能說明做不了。
06
低代碼不適合開發哪些類型的應用
很多專家啊，不但錯誤的認為低代碼搞不定復雜企業應用，還在低代碼適合哪些類型的應用上說錯了。
低代碼真正不太擅長的，是那些有各種特殊要求的應用，比如：
? 對算法和復雜數據結構要求比較高的：想不會有人想到用低代碼平臺去刷LeetCode題、打ACM比賽的吧。這里有個細微的地方是要區分是業務邏輯比較復雜還是算法邏輯比較復雜，業務邏輯復雜對低代碼來說不是問題，算法邏輯復雜才是問題。那啥叫業務邏輯復雜呢，就是業務人員總之是說的清楚，或者是能理解的；啥叫算法邏輯復雜呢，就是業務人員只能給個目標，具體怎么實現是不管的，就算解釋是一臉悶逼的聽不懂的。
? 對界面要求特別高的：比如游戲或抖音、云音樂這樣的社交娛樂型的應用。目前主流的低代碼平臺都不擅長做酷炫的界面（有一些特定類型的低代碼平臺如App Onboard是面向游戲開發的）。
? 頭部互聯網級應用：頭部互聯網應用用戶量巨大，為了優化性能有很多很多trick，前后臺技術架構非常復雜，低代碼平臺的實現是比較標準的數據庫 / 邏輯 / 界面三層架構，無法滿足性能需求。注意這不是說所有互聯網應用都不合適，只是指那些用戶量特大的頭部應用。
? 分析和智能化應用：分析類應用自然應該用更專業的BI工具，智能化應用應該用更專業的機器學習平臺等工具。
? 系統軟件、科學計算等其他專業性很強的應用。這個不多說了，估計沒誰想用低代碼來做，但多說一句，雖然這些系統的內核肯定不適合低代碼開發，但界面可是很適合，輕舟低代碼產品正是脫胎于云計算平臺的界面開發。
現在大家應該可以發現很多業界流行的觀點說低代碼適合這個那個的其實都是錯的，比如：
? 說低代碼適合“簡單的工作流和表單流轉的應用”：事實上專業的低代碼并不見得特別適合這類應用，比如Gartner就說OutSystems這方面的支持還不太好。其實最適合這類應用的反而是那些“表單驅動”的產品，這些產品并非專業的低代碼平臺。專業的低代碼平臺搞這些不是完全不行，但屬于大炮打蚊子，性價比不高。
? 說低代碼適合“生命周期短的應用”：事實上如果用OutSystems這樣“最專業”的低代碼平臺去做營銷活動頁這樣“生命周期短的應用”，肯定會欲哭無淚。為什么？因為營銷活動頁對界面的要求很高。
? 說低代碼適合“創新型應用”：有篇文章按Gartner的方法把應用分成基礎設施型（如 ERP）、差異化型（如 CRM）和創新型應用，說前兩類應用低代碼就別碰了，都是傳統IT的菜，低代碼就搞搞創新型應用，這個說法不對。互聯網App算典型的創新型應用吧，上面已經說過這個低代碼搞不定。
07
低代碼不是銀彈，不要過度神化
上面說低代碼很適合開發典型的企業應用，優點明顯，如開發人員上手快、開發效率高、增進溝通和集成等，但不要認為低代碼是銀彈，用了什么問題都解決了。原因主要有以下三個方面。
1）開發工具只能解決軟件研發的部分問題。作為開發工具，低代碼可以加快在需求比較明確時的軟件交付，可以在大方向比較明確但具體需求不明時加快軟件的迭代更新。但企業應用和企業的經營管理方式、業務方向、業務流程、組織架構密切相關，和人密切相關，這些方面如果有問題，軟件都不知道怎么做，這都不是開發工具所能解決，該請咨詢還是得請咨詢。低代碼就像特種兵，單兵作戰能力是強，但如果將帥不行，戰略戰術拉垮，打不了勝戰。
2）低代碼能提升多少開發效率缺乏權威數據，不要有太高預期。業界有很多對低代碼開發效率的宣傳，最多的是說什么提升10倍啦，這些一看就是胡扯。一些廠商和分析機構會發布提效數據，看似效果特別好，但因為前面說的無代碼和低代碼沒分清問題，這些數據不可信。比如阿里“宜搭”的數據說平均將應用開發成本從17.5人天提高到3.5人天，提效500%，但前面說過“宜搭”是無代碼工具。無代碼工具因為都是面向特定類型的應用高度優化的，提效明顯很正常的，但不通用。專業的低代碼廠商如OutSystems、Mendix，反而不敢宣傳提效多少倍，所以一個廠商宣傳的效果越好，就越不可能是專業的低代碼平臺。從經驗看，用低代碼做一些小系統確實挺快，但上了規模后還能是不是有數倍提升，覺得不大可能。根據初步經驗，覺得提升1到2倍是一個比較合理的預期。
3）行業典型的項目制限制了低代碼的價值。低代碼平臺因為可視化、效率高，最適合業務和開發密切溝通合作，快速迭代。但當前甲乙方之間典型的項目制要求雙方提前簽訂詳細的合同和SOW，這就把本來可以敏捷開發的生生打回到瀑布模式，這樣低代碼快速迭代的價值就很難體現。項目制存在太久，不是一時半會改的了的。
08
小結
? 無代碼和低代碼不是一個層次的概念。低代碼是以OutSystems、Mendix等產品為代表，主要面向專業開發的通用應用開發平臺；無代碼則是一個營銷用語，用于形容很多種面向業務人員的工具，如應用搭建、在線表單、工作流等。不存在無代碼的通用應用開發平臺。無代碼這個概念過于寬泛，未來很可能會慢慢淡出市場。
? 要判斷一個低代碼平臺是否專業，可以重點看模型驅動、可視化開發、表達式語言、軟件工程、開放集成和腳本語言等六個方面。對照這些標準，國內還很少有專業的低代碼平臺，雖然輿論甚是喧囂。
? 業界關于低代碼適用場景的觀點大多數都是錯的。比如業界很多人講低代碼搞不定復雜的企業級應用，但都毫無根據。從技術原理出發，低代碼其實最適合做的就是企業應用，即便是CRM、ERP這樣復雜的應用；業界認為低代碼適合做“簡單的工作流和表單流轉的應用”、“生命周期短的應用”、“創新型應用”等觀點都是錯的，這些應用很多恰恰不適合低代碼。
? 低代碼不適合做的應用是對算法、界面、性能、分析和智能化等專業性要求高的應用。
? 低代碼對企業應用開發價值明顯，但不是銀彈，不要過度神化。
對甲方來說，認為CIO們應該從試點應用做起，通常來說要求團隊用低代碼的阻力會很大，但可以要求乙方用低代碼，降報價。對乙方，覺得短期很難賣平臺，最好是和甲方談個人力外包模式，避免項目制的僵化。業界說低代碼是“高級外包”倒沒說錯，雖然覺得既然用的是低代碼應該叫“低級外包”更合適。
最后的最后，再次呼吁分析機構能夠區分低代碼和無代碼，聚焦分析面向通用應用開發的低代碼開發平臺，促進這個行業的認知統一，產品的標準化，這樣才能夠推動行業發展。
無代碼將死，低代碼長存！
Mendix低代碼開發
一、Entity實體與Object實例
Entities實體 抽象的容器
Object實例 具體的一個真的物體
一個entity包含很多的Object
Entity: 課程 Name 價格 課時
Object: 語文 語文 100 20
數學 數學 110 30
英語 英語 70 10
Entity: 人 性別 身高 體重
Object: 張三 男 175 160
李四 男 180 150
二、MicroFlow 微流實現業務邏輯
–添加業務邏輯到App中，實現app對數據的自動處理
###1.Microflow 微流
實現app自動化
類似：if for case 子函數 function
Mendix: 建模、拖拽、圖形化編程：實現自動化邏輯
2.何時使用微流
1.Change default behavior 擴展、修改默認操作
create button 按鈕+輸入判定 （新建course且課程收費必須在100-200塊）
2.Business specific process 業務定制話流程/特別的計算公式：剩余預算=合同額-（實際費用+售前費用）
3.System integration 系統集成：數據庫，Tc，web-service，人工智能算法
1）Mendix官方開發的一些Widget其實也是微流：
比如create button 其實也是個微流
Create button = 創建Object實例+展示一個界面show a age
用來解決標準的業務邏輯
2）Microflow微流解決客戶定制化的業務邏輯action
Create button = 創建object實例+展示一個界面show a page +價格的判定
三、實踐-微流使用
需求1：在課程列表添加一個按鈕，點擊這個按鈕就可以選中這門課，為這門課安排培訓事件

需求2：通過培訓的開始時間，以及這門課持續的時間，自動計算
思路：結束時間=課程開始時間+課程持續時間

需求3.某次培訓參加人數的總和
思路：當學員注冊的時候，獲取學員注冊的課程，然后查找這個課程下所有注冊學員的總數。

四、數據的有效性與一致性檢驗
數據校驗
根據真實的業務邏輯，用戶在輸入數據的時候，在Mendix中去驗證一個數據是否符合業務要求。
Mendix數據的信息、值保存在哪？
Attribute特征中，屬性值
Association中：關聯關系的值，也就是箭頭的指向
在Domain Model中驗證Attribute特征數據的有效性

###1.利用Validation Rules（這個名詞，只能針對Domain Model中的Attribute數據校驗）
六種驗證規則
Required 必填，Unique 唯一，Equals =某個值，Range 范圍，Regular express 正則表達式，
郵箱：¹+@[a-zA-Z0-9_-]+(.[a-zA-Z0-9_-]+)+$
Maximum length 最大長度
2.在Microflow中驗證Associations關聯關系數據的有效性
例如：周四的數學課這個TrainingEvent,必須把它和課程、老師、上課地點關聯在一起。
但這個關聯關系的指向不能再Domain model中用Validation Rule做判斷
這個時候我們就要利用微流中的Decision來做數據有效性 的判斷
如何寫Decision表達式：
也就是微流表達式
調用一個Attribute值：$EntityName/AttributeName
$TrainingEvent/StartDate!=emptyAND調用一個Association的指向（值）：$EntityName/ModuleName.Association
$TrainingEvent/MyFirstModule.TrainingEvent_Course != empty

3.數據的刪除
在新建一個Association時，它就會要求我們設定刪除方式
一共有三種刪除方式：
舉例：Registration和TrainingEvent
A. 當刪除TrainingEvent時:
保留所有與它相關的注冊信息
同時也刪除所有與它相關的注冊信息（Cascading Delete）
只有當TrainingEvent沒有關聯任何注冊信息，它才能被刪除
選第三種方式！！！
B. 當刪除Registration時：選第一種方式
Registration注冊信息-----Trainee學習
1.刪Registration時，Trainee不受影響，所以選第一種
2.刪Trainee時，所有與他相關的注冊都刪了，選第二種方式
五、權限管理
一、Mendix權限管理概要
Mendix的權限管理在兩個地方實現
Project Security:設置app總體安全級別和配置總體權限
Module Security：設置具體的每個頁面page，微流microflow，實體entity甚至特征attribute的讀寫權限
只需要通過點擊配置實現！
三種安全級別

二、兩種角色：User Roles與Module Roles
我們要將Module Roles和User Roles鏈接在一起！
1）是將Module Roles賦值給User Roles
2）然后再將User Roles和我們終端用戶的賬號綁定
三、權限配置的基本步驟
四、其他配置

參考鏈接
https://mp.weixin.qq.com/s/OXCBORheAx99o3fS-ZfUdg
https://blog.csdn.net/qq_38352351/article/details/110160054

---

1. A-Za-z0-9\u4e00-\u9fa5 ??

總結

以上是生活随笔為你收集整理的低代码技术与市场（Mendix与 OutSystems）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。