Fat Person

我实际测试了,确实是type直接写是可以的,  另外还发现了一个神奇的事情,如果我俩都写成block.  死递归了 飞书如何联系,怎么添加呢?

已经申请,通过一下谢谢

..实测了好几次..还确实是,另外commit也不会触发 Aop.TraceAfter.. 而实际上数据库的数据变了已经

哦对了,这个只会出现在 using var dbTran = xx.CreateUnitOfWork(); using var tranInstance = dbTran.GetOrBeginTransaction(); 混用的场景 单独使用dbTran.Orm没问题

您需要哪里的截图，我提问里头的如果不够您说，我目前还未修复，感觉是依赖版本不正确，但是由于是直接docker拉的，也不知道怎么个升级顺序了

 webui 也启动不了

谢谢指导,目前第一个版本已经出来了 大概说几个容易误导的,至少是误导了我的. # 但是!其实组件库很哇塞!纯属因为文档没有说! 1. 其实该组件库的定制性相当强,并不是非得按照demo说的一直走 2. demo的最佳实践,他们的分层是没有问题的,但是他们的封装并不是代表着这个库必须得这么封装 3. 本质上你可以跳过他们自带的context来做任何事情,例如:自己管理状态,变量,而组件库提供了大量的API已供你这么做 4. 如果你想让这个组件库成为纯dump组件或者纯展示组件亦是可以的,并不一定非得按照demo的封装走那一套,例如:可以跳过封装base-node,这个也不是必须.只是单纯的渲染操作而已 5. 最佳实践里头尝试使用了字节的ui库+form渲染,这部分其实也可以不用,不然你就真得跟着DEMO完全抄下去了. 6. 留意oninit的ctx对象,API文档说的很多函数,例如fitview等等,在这里又被分到不同的属性对象里头了(其实我觉得这个分了更合理,但是文档就是写的是个函数,也没头没尾的) 7. 从目前demo来看,这个demo其实真的是字面的demo,不能称为"最佳"实践,其实这个组件库的上限很高,看你怎么玩. 8. 重要的事情说3遍,一定要把这个组件库单独理解,不能奔着"最佳实践"就是真理,单独理解组件库的设计,很哇塞!,一定要把这个组件库单独理解,不能奔着"最佳实践"就是真理,单独理解组件库的设计,很哇塞!,一定要把这个组件库单独理解,不能奔着"最佳实践"就是真理,单独理解组件库的设计,很哇塞!