对象结构，自动化metadata扫描，自动化api和界面生成，一起都很美好。经过一番研究后个人觉得不适合企业应用开发。
简化前端开发流程，同时控制开发成本，提高灵活性，连接多种客户端，对接第三方系统。反反复复琢磨了快15年了吧，这是一点也不夸张。传输格式从xml，到xaml, 到json, 到二进制的压缩格式。自己定义的rpc, 到jsonrpc, grpc, rest。自描述的树型类型系统，自描述的rpc签名，类似swagger的交互式文档系统。但现在openapi, json-ld，graphQL。客户端生态，closure-tools, GWT, pajamas, reactjs, vue, angular，都折磨了很久。是的，我没有学过DCOM, WebService，EJB, 我觉得这些方案不实用，个人偏见。
今天我说这样的结论：这种方式不适合企业应用开发。
对象模型是原罪
这类自动化开发的基础是metadata, 而metadata是基于固定结构的对象。现实开发中显示出的数据90%是这种类型的，显示，导出，增删改，过滤条件，到可以自动生成 。这是自动开发最核心的价值。说是在的，这种思路30年前就有了，数据字典，PB，还有一些围绕dBase, foxBase的工具。
98%的数据，可以从90%的数据中简单推导而来，比如用表达式领域语言，FP函数，从已有的90%的数据中，加加减减，或者简单的查询得到。有些别扭，但可以接受。各种框架的支持度上，和方便程度上有差别。支持度不够，或者特别麻烦，会极大的影响开发。
2%的数据，和对象模型很不契合，是对数据的深度加工。这时要套入自动开发模型就变得非常复杂。为接口实现完整的栈，从对象结构，到描述，到削足适履的接口实现。原先自动的persisit层都要手工完成。
对象reshape，对象链接变得复杂
graphq，json-ldl 是解决这类问题的目前最好的答案了。但是复杂和抽象程度，后台实现的效率都是难以接受的
庞大的对象结构和不必要的数据传输
为了开发方便，实体对象里堆砌了大量的字段，关联的一对一，一对多，多对多的实体，导致了数据急剧增长。图形的对象结构出现都不稀奇，导致获取完整对象到客户端在现实中是比可能的。
有四种应对办法：
- 仔细控制系列化的范围，用不到的字段不传输，用不到的关联实体不传输
- 按需加载关联的实体对象和数据量大的字段（比如图片和文件）
- 为接口单独定义类结构，把业务模型和接口模型断开
- 用graphql， 只传需要的数据
第一种方法的问题在于，要仔细平衡方便和性能的关系。这非常的繁琐，考虑到不同的接口会用到不同的数据，这是不切实际的方案。
第二种方案使用透明的代理，在访问数据到需要的数据时再加载，比第一种要好很多。缺点是有时会触发严重的性能问题，比如扫描所有属性的自动化程序，或者只是检查一下集合属性的个数；访问一对多对象里的一对一对象（大量的碎片化请求）。对框架的实现有较高的要求，比如控制好按需加载的颗粒度，批量化处理碎片化请求（收集碎片化异步请求调用，批量化发给服务器），或者使用http2（对服务器配置，反向代理等有一定的要求）
第三种方法，为接口定义类结构，接口上比较干净，接口之间比较独立，维护起来比较没有相互牵扯，分给多人工作也不相互影响，性能也可以精确控制。就有一点：开发太麻烦了。接口模型和实体模型的映射关系，metadata，都要手写，而且很繁琐。另一方面，相似接口的存在很头疼，复制代码还是不复制代码，测试还是不测试都是纠结的问题。如果语言支持 mixin, 比如golang, 或者各种脚本语言，可以在mixin层次得到复用，一定程度上解决了这个问题，但因复用mixin引发一定的couple问题。复用mixin需要一定的技巧和心血，其实一般的企业软件开发人员达不到这个水平。
第四种方法，要求水平太高了，而且性能问题也不容易解决。另外复杂的数据结果，用graphql也是推导不出来的。
对象模型不适应现实需要
OOP是一个迷思，大家认为对象化，是必须的，有效的方法。其实是不正确的。在现实中需要的不是对象模型，而是视图模型。
每个人看到的不是椅子，而是椅子的某个视图，不同的投影方法，得到的椅子不同。
产品从厂家到使用者之间，总是要通过不同的渠道。使用者不关心产品的模型和生产过程，关心的是和他接口的渠道。
椅子的实体模型固然重要，但更有用的是面向不同场景的不同视图。不分场景一股脑的使用实体模型，必然导致代码复杂，繁琐，效率底下，用户使用起来也麻烦。
割裂客户端和服务器端开发成本过高
同步开销
需要同步对象结构，当然我们可以通过工具，提前或者实时同步。但问题在于同步工具会变成瓶颈，好用的同步工具很少，开发环节的自动化工具也需要开发和配置。如果同步工具是现有的，有可能缺乏需要的功能；如果是自己开发的，开发成本很高
另外，不能不考虑模型的量级，成百上千的实体模型，他们的metadata是很庞大的，都预先同步到客户端也是很大的开销，如果动态加载，策略也比较复杂。
前后端割裂开销
如果不能独栈开发，前后端分两个人，前后扯皮会比较严重，损失效率
前后端语言不统一
使用nodejs没有这个问题，但是nodejs相比java,php,csharp,这些生态不成熟。
使用传统语言的后端，要么对于开发人员要求很高，要么割裂前后端。另外前后端可能存在重复的逻辑代码和对象模型
从技术角度来说，这些都不是问题。但和有着大量用户的消费软件不同，企业用户量少，访问频度低，业务逻辑复杂，变动快，实体对象多，功能多（菜单有上百项再正常不过了）。每个功能上的开发费用非常有限。使用上些许不便，卡住半秒一秒，是可以接受的。割裂前端后端造成的成本开销是没有必要的。企业开发只能选用成熟的技术框架，至少现在我觉得还不够成熟。
基础的CRUD，传统方法（比如MVC）处理起来也很简单，复杂的依然复杂。完成有价值工作的不是框架，是我们自己。在headless 模型在成本上只有增加，没有降低的情况下，没有使用的必要。
在需要的场景，比如易用性要求高的销售，实时性要求高的工厂，使用新框架是必要的，必须的。用户也愿意拿出更多的资金，因为这两环节的优化能帮助销售，提高生产效率。而企业内控，关注的是可靠，一个岗位做重复同样的工作，方便与否常常不那么重要，工作时间更多的是做决策，而不是填单子，卡住半秒，不会影响工作效率。过于仔细的实现功能是没有必要的。