jeecg理解
程序员文章站
2023-12-24 15:01:09
...
写这篇博文有两个目的，一个是做任务，一个是记录下来我对jeecg项目的理解，抛砖引玉，欢迎大家吐槽，拍砖和人身攻击就不要了，违法。
言归正传，下面进入正题。
从历史角度谈下jeecg出现的可能性，必要性，以及能够解决当前项目开发中的什么问题。
从面向对象语言出现开始，编程不再局限于逻辑性思维，而开始往工程学靠拢。面向过程的开发语言在大型项目中很难形成统一规范，也难以实现通过规范化的文档和人们的共识去协作开发一个项目，面向过程的开发方式往往是一个人的设计思路，完成一个项目，这种方式开发模式是无法发挥优势的，或许这个时候程序本身就是一种开发模式，但其他开发者可能对这种开发方式一窍不通，或者理解不够到位。面向对象的开发方式使人们开始可以以共同的规范，按照相同的设计模式和设计思路来进行开发。这时候人们可以把一个整体的项目分成不同的模块，然后通过相同的设计模式和设计思路来进行开发不同的模块，然后合并到一起，形成一个完整的项目，实现人类的信息化进程。此时一个项目可能会解决一种信息需求，比如实现一个论坛系统，来解决人们一群人沟通的需求和讨论某个专题的需求；或者一个学习系统；或者学校里的一个网站；或者学校里面一个学院的一个网站；或者一个专业的网站；或者一门课程的网站；或者一个学分管理系统等等。此时的信息系统使用的是各个程序员或团队自己熟悉的开发模式，数据库和框架甚至语言。比如早起的mvc开发模式，webwork框架，struts1框架，ejb框架等。然而每种框架都存在其优点和缺点，于是开始出现框架之间的协作和融合，我们最熟悉的也是现在应用最多的ssh框架。框架的出现使开发模式变得更加规范，各种中间件也开始出现，以便解决遇到的各种问题。比如hibernate的出现，屏蔽掉了数据库之间的差异。spring的出现消灭掉了配置文件而使用约定大于配置的方式实现。前端页面也从被动接受css的布局控制变得更加灵活。js的出现使网页变得不再只是固定不变的，而是可以动态改变的，局部改变而无需全部刷新。js由于其兼容性差和作为一门语言太过随意，急需一种规范来约束其太随意的毛病，于是出现了js框架。js框架的出现不仅解决了大部分的浏览器兼容性问题，更是将通用的功能做成接口，直接配置就可调用。这时候的系统开发已经变得不再复杂，只要提前设计好数据库，然后通过模式在各个层次实现好各自的部分，程序就可以运行成功。这时候的业务设计是放在数据库设计的时候体现的。随着人们对开发的熟悉，发现约定大于配置和分层的方式有一种好处，就是一旦设计好了数据库，起好了实体类的名称，各个层次之间的有关联的模块是可以以一种规范进行约束的。比如用户表userinfo，在实体bean里面可以起名UserInfo,那么所对应的持久层就可以起名UserInfoDao和UserInfoDaoImpl，service层可以起名UserInfoService和UserInfoServiceImpl.这种规范的出现不仅使开发过程中各个模块之间的方法不至于错误调用，解决了起名的麻烦，更是同一层的模块可以统一管理。于是出现了开发工具级别的代码生成工具。只要设计好数据库，就可以用代码生成工具按照既定的规范把不同的模块进行划分之后生成不同层次的代码。这时候后台程序开发效率开始成倍提升。可是这种开发方式还有局限性的，就是有些系统的业务是时效性很强的，比如一个信息系统是随着政策的改变要随时能够修改的。这时候需要频繁的改变业务方面的数据库和页面（其他可自动生成）。这不仅带来了开发的麻烦更使开发变得琐碎，枯燥和无趣--既没挑战性又无成就感。那么如果数据库的生成能够放到页面上进行设计，设计完成之后自动生成数据库和各层次的代码以及页面模块元素的话，不仅能够提高开发效率还能减少对数据库的设计带来的门槛。于是onlinecoding模式应运而生。此时各种开发模式都已经成熟，只要结合好页面和数据库方面的对应关系，然后用现成的中间件调用数据库的ddl等命令就行。此时网页生成代码和页面（即智能代码生成）已经变得可能。
早期的系统之间是不存在任何的关联的。系统作为一个管理数据的服务器程序，内部的数据是通过后台手动输入进去的。此时系统之间没有任何的联系，除非在不同系统里面相 同模块输入相同的数据。这也就是所谓的信息孤岛问题，系统之间没有数据间的关联性和流动性。后来人们为了给这些系统之间相同的数据对接，形成了集成系统项目和单点登录等技术。此时的信息系统之间解决掉了部分数据不一致问题，也修补丁似的缓解了信息孤岛问题。然而系统之间由于开发者的不同，所选择的开发模式可能不一样，用到的工具方式等可能也不一样，甚至用到的语言都不一样。虽然补丁似的缓解了信息孤岛问题，但随之带来了维护难度的增加和扩展性和灵活性的减弱。因为越多的开发方式要求程序员掌握越多的技术，越需要揣摩先前开发者的思路。甚至有些程序读起来晦涩难懂，尤其当敏捷开发没有注释和文档的情况下。这时候甚至出现一种怪现象：程序员宁可自己开发也不愿意改变原有的代码。这最明显的原因是改动源代码将会造成更多bug的出现，而解bug往往占据开发过程中不可小觑的一段时间。于是更多的人开始选择自己开发。但是开发的多了后会发现，系统是存在共同的模块的，比如通讯模块，邮件模块，文件上传下载模块，用户权限管理模块。只是每个系统略微有差异，总体是一样的。人们开始找开源的通用系统，但大部分系统要么通用性不够，要么规范性不强，有一些系统将用户角色权限模块的关系全部设置成了多对多关系--看似通用，实际上很考验超级管理员的智商（即便是个开发者）。有一些开发者确实做了部分的不错的通用模块，但是很多是商用的并且定价不菲。由于商用的局限性，产品的更新换代总是需要一段时间。人们都渴望有人开源一个通用的基础系统供大家一起使用，一起完善。此时此刻，无论是哪种开源基础系统都将具备极强的生命力，而jeecg成为了第一个。
jeecg解决了通过网页配置系统而无需手动设计数据库的新模式。解决掉了开发过程中通用模块的重复劳动，然后作为开始版本的jeecg也有其缺点和不足，最重要的一点是jeecg最适合的是企业项目，这是它的领域。还有jeecg可以自动生成关系简单的模块，如果关系复杂的很的话，用jeecg来设计不仅不能提高开发效率，甚至会使你抓狂到不行。也就是jeecg是半智能。需要根据实际情况判定需不需要使用jeecg。如果系统注重效率和并发等特性的话，还得依具体情况择优使用jeecg的模块。jeecg也需要等待历史的检验。
从结构上剖析一下jeecg系统。以3.5.0为例
jeecg3.5.0 非maven 版本使用的技术框架就是文档里面写的，springmvc，minidao，easyUI等。jeecg系统本身自带了企业系统的通用功能，如用户权限角色模块，报表模块，文件上传下载模块，消息模块等。这些模块的代码使用了注解，反射，代理等机制，再结合面向切面的扫描和处理，使代码量减少到很少。自动表单结合数据字典和ddl
语句变得可能。增强sql采用深入拷贝，将对象转换成流进入jvm。activiti工作流引擎可以设计流程，结合智能表单系统，可以把企业大部分的业务包含进来。
对jeecg的理解还处于门外汉的阶段，接下来的时间要好好研究一下jeecg系统每个部分的设计细节和技术内容，有了新发现会继续写下来记录一下的。
言归正传，下面进入正题。
从历史角度谈下jeecg出现的可能性，必要性，以及能够解决当前项目开发中的什么问题。
从面向对象语言出现开始，编程不再局限于逻辑性思维，而开始往工程学靠拢。面向过程的开发语言在大型项目中很难形成统一规范，也难以实现通过规范化的文档和人们的共识去协作开发一个项目，面向过程的开发方式往往是一个人的设计思路，完成一个项目，这种方式开发模式是无法发挥优势的，或许这个时候程序本身就是一种开发模式，但其他开发者可能对这种开发方式一窍不通，或者理解不够到位。面向对象的开发方式使人们开始可以以共同的规范，按照相同的设计模式和设计思路来进行开发。这时候人们可以把一个整体的项目分成不同的模块，然后通过相同的设计模式和设计思路来进行开发不同的模块，然后合并到一起，形成一个完整的项目，实现人类的信息化进程。此时一个项目可能会解决一种信息需求，比如实现一个论坛系统，来解决人们一群人沟通的需求和讨论某个专题的需求；或者一个学习系统；或者学校里的一个网站；或者学校里面一个学院的一个网站；或者一个专业的网站；或者一门课程的网站；或者一个学分管理系统等等。此时的信息系统使用的是各个程序员或团队自己熟悉的开发模式，数据库和框架甚至语言。比如早起的mvc开发模式，webwork框架，struts1框架，ejb框架等。然而每种框架都存在其优点和缺点，于是开始出现框架之间的协作和融合，我们最熟悉的也是现在应用最多的ssh框架。框架的出现使开发模式变得更加规范，各种中间件也开始出现，以便解决遇到的各种问题。比如hibernate的出现，屏蔽掉了数据库之间的差异。spring的出现消灭掉了配置文件而使用约定大于配置的方式实现。前端页面也从被动接受css的布局控制变得更加灵活。js的出现使网页变得不再只是固定不变的，而是可以动态改变的，局部改变而无需全部刷新。js由于其兼容性差和作为一门语言太过随意，急需一种规范来约束其太随意的毛病，于是出现了js框架。js框架的出现不仅解决了大部分的浏览器兼容性问题，更是将通用的功能做成接口，直接配置就可调用。这时候的系统开发已经变得不再复杂，只要提前设计好数据库，然后通过模式在各个层次实现好各自的部分，程序就可以运行成功。这时候的业务设计是放在数据库设计的时候体现的。随着人们对开发的熟悉，发现约定大于配置和分层的方式有一种好处，就是一旦设计好了数据库，起好了实体类的名称，各个层次之间的有关联的模块是可以以一种规范进行约束的。比如用户表userinfo，在实体bean里面可以起名UserInfo,那么所对应的持久层就可以起名UserInfoDao和UserInfoDaoImpl，service层可以起名UserInfoService和UserInfoServiceImpl.这种规范的出现不仅使开发过程中各个模块之间的方法不至于错误调用，解决了起名的麻烦，更是同一层的模块可以统一管理。于是出现了开发工具级别的代码生成工具。只要设计好数据库，就可以用代码生成工具按照既定的规范把不同的模块进行划分之后生成不同层次的代码。这时候后台程序开发效率开始成倍提升。可是这种开发方式还有局限性的，就是有些系统的业务是时效性很强的，比如一个信息系统是随着政策的改变要随时能够修改的。这时候需要频繁的改变业务方面的数据库和页面（其他可自动生成）。这不仅带来了开发的麻烦更使开发变得琐碎，枯燥和无趣--既没挑战性又无成就感。那么如果数据库的生成能够放到页面上进行设计，设计完成之后自动生成数据库和各层次的代码以及页面模块元素的话，不仅能够提高开发效率还能减少对数据库的设计带来的门槛。于是onlinecoding模式应运而生。此时各种开发模式都已经成熟，只要结合好页面和数据库方面的对应关系，然后用现成的中间件调用数据库的ddl等命令就行。此时网页生成代码和页面（即智能代码生成）已经变得可能。
早期的系统之间是不存在任何的关联的。系统作为一个管理数据的服务器程序，内部的数据是通过后台手动输入进去的。此时系统之间没有任何的联系，除非在不同系统里面相 同模块输入相同的数据。这也就是所谓的信息孤岛问题，系统之间没有数据间的关联性和流动性。后来人们为了给这些系统之间相同的数据对接，形成了集成系统项目和单点登录等技术。此时的信息系统之间解决掉了部分数据不一致问题，也修补丁似的缓解了信息孤岛问题。然而系统之间由于开发者的不同，所选择的开发模式可能不一样，用到的工具方式等可能也不一样，甚至用到的语言都不一样。虽然补丁似的缓解了信息孤岛问题，但随之带来了维护难度的增加和扩展性和灵活性的减弱。因为越多的开发方式要求程序员掌握越多的技术，越需要揣摩先前开发者的思路。甚至有些程序读起来晦涩难懂，尤其当敏捷开发没有注释和文档的情况下。这时候甚至出现一种怪现象：程序员宁可自己开发也不愿意改变原有的代码。这最明显的原因是改动源代码将会造成更多bug的出现，而解bug往往占据开发过程中不可小觑的一段时间。于是更多的人开始选择自己开发。但是开发的多了后会发现，系统是存在共同的模块的，比如通讯模块，邮件模块，文件上传下载模块，用户权限管理模块。只是每个系统略微有差异，总体是一样的。人们开始找开源的通用系统，但大部分系统要么通用性不够，要么规范性不强，有一些系统将用户角色权限模块的关系全部设置成了多对多关系--看似通用，实际上很考验超级管理员的智商（即便是个开发者）。有一些开发者确实做了部分的不错的通用模块，但是很多是商用的并且定价不菲。由于商用的局限性，产品的更新换代总是需要一段时间。人们都渴望有人开源一个通用的基础系统供大家一起使用，一起完善。此时此刻，无论是哪种开源基础系统都将具备极强的生命力，而jeecg成为了第一个。
jeecg解决了通过网页配置系统而无需手动设计数据库的新模式。解决掉了开发过程中通用模块的重复劳动，然后作为开始版本的jeecg也有其缺点和不足，最重要的一点是jeecg最适合的是企业项目，这是它的领域。还有jeecg可以自动生成关系简单的模块，如果关系复杂的很的话，用jeecg来设计不仅不能提高开发效率，甚至会使你抓狂到不行。也就是jeecg是半智能。需要根据实际情况判定需不需要使用jeecg。如果系统注重效率和并发等特性的话，还得依具体情况择优使用jeecg的模块。jeecg也需要等待历史的检验。
从结构上剖析一下jeecg系统。以3.5.0为例
jeecg3.5.0 非maven 版本使用的技术框架就是文档里面写的，springmvc，minidao，easyUI等。jeecg系统本身自带了企业系统的通用功能，如用户权限角色模块，报表模块，文件上传下载模块，消息模块等。这些模块的代码使用了注解，反射，代理等机制，再结合面向切面的扫描和处理，使代码量减少到很少。自动表单结合数据字典和ddl
语句变得可能。增强sql采用深入拷贝，将对象转换成流进入jvm。activiti工作流引擎可以设计流程，结合智能表单系统，可以把企业大部分的业务包含进来。
对jeecg的理解还处于门外汉的阶段，接下来的时间要好好研究一下jeecg系统每个部分的设计细节和技术内容，有了新发现会继续写下来记录一下的。