低代码技术与市场（Mendix与 OutSystems）
低代码技术与市场（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\u4e00-\u9fa5]+@[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 != empty AND
调用一个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
文章来自于网络，如果侵犯了您的权益，请联系站长删除！
