在3月的时候就接触了jeecg-boot了,以前我是一个python开发者,python是一个动态型语言,可以很简单的配置生成后台管理器,动态注册页面,只需要按组件的方式register页面就可以了,最典型的就是xadmin
的方案,但是其有个弊端就是可扩展性差,性能也差.作者也慢慢弃坑了,但是作者现在正在做一个新的方案前后端分离xadmin…
说回正题,在java里面,我怎么都想不到动态生成后台的方式竟然是用代码生成的方法,然后再拷贝到相应文件目录下(一般做法).由于java的是一个强类型语言,固然是没有python脚本语言组件式开发组件式注册加载来的要简单…
在我接触到jeecg之后,我第一个反应当然是要穷举啊,要把世上的好东西都看尽啊,所以当时也看了以下的一些项目:
当然,也顺藤摸瓜,找到了jeecg的模板引擎的版本:Jeecg 微云快速开发平台
作为个人爱好开发者,我并没有过多的深入到代码的层面去看每个框架的代码质量如何,而是简单
的从社区、活跃度、个人开发还是团队开发、系统易用性、文档使用、视频教程这几个简单的角度去考量,显而易见,每一家都有每一家的闭环系统以及生意,都有其优点,但是jeecg这个选择还是十分强大,特别是在线表单开发、流程设计、图表配置这几个功能真的很亮眼,只需要简单配置,可以满足基本的后台开发设计。
最重要的是,随着前后端分离开发的时代来临,以及微服务架构应对大数据的趋势,jeecg团队保持技术上的更新,尽管这可能并不会问他们带来更多的经济效益,但是他们对技术的执着,在前端选型上,选择了大公司维护的ant-design-pro方案,当然也有其他很优秀的方案比如easyUi\elementUi\D2admin,但是考虑社区、更新活跃度,当然是ant好,同时也要时时更新的代价了。jeecg表示在后续会有微服务架构版本,而且会保持一贯强大如issue所提:
统一单点登录平台、cms内容管理系统、支持多站点、集群部署
好了,接下来就是我对jeecg-boot使用的一些心得了:
大小写以及url、controller方法名映射都是十分具有意义规范,但是对于一般开发者来说,如果不指明其开发的规律的话很难体会到
其实还有很多心得就是相当于jeecg-boot文档的介绍了,接下来站在小白个人开发者,说一说我对jeecg-boot的一些建议吧:
以及github issue 以及qq群
对于开发者,如果没有一套规定的流程,会在这几个地方疲于奔命,分散了大部分注意力.
但是,也没有笔者更好的方案了.
尽管在论坛上能够找到更新日志、但是我仍然建议在文档处写上更新日志,在版本迁移时,也在对文档进行版本迁移的说明. 或许考虑gitbook 开放文档,让每个人都可以提交pr,并不是说官方写的文档就一定是最好的。文档版本管理、文档贡献、文档搜索.后期完整视频放出的时候,可以在文档对应小节插入视频地址。
可以在群里看到,管理员们被群里的新来的小伙伴各种问题问到注意力极度分散了,建议在群里设立一个机器人qq助手
可以录入faq在此,让人们自助提问自助找到关键词,找到文档,解决重复性问题.
让开发者自助开发各自的插件来达到自己的目的(如文件上传、第三方oauth集成、其他组件集成),比如说jeeXX就是自己一家从cms、oa、工作平台一系列都做了,但是如果jeecg能提供一套易用的插件机制,来让开发者利用此平台来开发自己的小应用,然后收集展示或者说交易…(开个脑洞类似php的微擎)
比如说字典数据,db初始化的时候,就已经有20+数据了,但是作为使用者我想我开始不需要关心一些jeecg-boot默认的配置字典,希望提供一个筛选 区分系统数据与用户自行添加的数据,这样不至于太冗杂。其他数据表、test等数据表亦是如此.
希望在开发的时候能多提供一个纯净版选择,如图
是完全前端静态化的,可以可选提供,两种模式让开发者自行把握.(简单说就是我觉得功能有点重了,若不是坚定信念,一开始被如此多的页面容易吓退却.)
数据库字段最大255,如果遇到富文本信息的系统,基本是超过255的,所以可以这里提供提示告知用户,要么截断,要么longtext(mysql),但是长期的日志积累,势必是一个很大的内存消耗.
当然,以上建议是十分理想化的,开源也是需要盈利的,感慨圈内的模式都是如出一辙,在新时代的今天,2b的公司需要生存,我觉得就要与时俱进,除了前线业务能力过强的同事、配合上辛勤工作的开发人员以及售后支持,我觉得现代化的社区论坛、开发方式、协同沟通方式也是必不可少的,或许这样并没有什么大用处(经济效益),始终觉得与其更好,不如不同。
本人技术和业务经历尚浅,不能提出像快速开发框架推荐使用 jeecg-boot如此有见解的的问题以及解决措施…