声明：ITeye精华文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！
JEECG（J2EE Code Generation）是一款基于代码生成器的智能开发框架，采用代码生成+手工MERGE半智能开发模式，可以帮助你解决Java项目中50%的重复工作，让你更多关注业务逻辑。
JEECG论坛：
http://www.jeecg.org
在线演示：
http://demo.jeecg.org
入门视频：
http://www.jeecg.org/forum.php?mod=viewthread&tid=197&extra=page%3D1
为了使大家对JEECG有进一步的了解，本期我们采访了JEECG的作者
张代浩。
ITeye期待并致力于为国内优秀的开源项目提供一个免费的推广平台，如果你和你的团队希望将自己的开源项目介绍给更多的开发者，或者你希望我们对哪些开源项目进行专访，请告诉我们，发站内短信给ITeye管理员或者发邮件到webmaster@iteye.com即可。
先做个自我介绍吧！
我叫张代浩，英文名scott，属于北漂一族，09年毕业后一直从事金融、对日方向的Java开发，期间在日本东京工作过一段时间。目前在一家重工企业，从事ABAP开发和Java开发工作。
我的博客：
CSDN博客、
ITeye博客
我的邮箱：zhangdaiscott@163.com
JEECG是什么? 有哪些功能？
JEECG全称为J2EE Code Generation，即J2EE代码生成器。这是一款基于代码生成器的J2EE智能开发框架，WEB架构基于零配置思想，使用SSH2+EasyUI技术架构。目前 JEECG 的最新版本为2.1.0。
JEECG宗旨：
提高开发效率、提高代码质量，打造一个快速开发平台。
JEECG可以有效解决信息孤岛问题，生成统一代码、统一规范、统一设计思路，使你能在这个平台上，快速开发出高效高质量代码，缩短开发周期，降低项目成本。
JEECG详细介绍：
http://www.iteye.com/news/26937
JEECG的主要功能如下（*表示JEECG的创新点）：
- (*)封装完善的基础模块：用户权限+数据字典+常用共通封装（定时任务、短信接口、邮件发送、Excel导出等）；
- (*)代码生成器：开发效率非常高，单表数据模型和一对多（父子表）数据模型的增删改查自动生成，功能直接使用；
- (*)查询条件生成器：查询功能自动生成，后台动态拼SQL追加查询条件；支持多种匹配方式（全匹配/模糊查询/包含查询/不匹配查询）；
- (*)页面表单校验器：采用EasyUI检验机制，表单校验生成器自动生成（必须输入、数字校验、金额校验、时间控件等）；
- (*)集成简易报表：Highcharts图像报表和数据导出非常方便，可极其方便的生成pdf、excel、word等报表。
- 常用共通封装（数据字典/邮件发送/定时任务/短信接口/Freemarker工具类等）
- 兼容IE 6、IE 8+和Google等浏览器
- 支持SQL Server、Oracle和MySQL等主流数据库
开发这个框架的初衷是什么？这不就是一个SSH2框架吗？
Java开发是从08年开始，刚参加工作的时候也喜欢追求新技术，感觉那样才能提高自己的能力，后来喜欢研究底层架构，研究了很多技术架构，也试着重写了struts1、spring。但是随着工作久了，慢慢发现研究技术、研究架构意义并不大，Java的新技术层出不穷，更新不断，对于项目来说提高开发效率，提高代码质量才是关键。所以项目中我开始注意抽取共通、设计规范和封装工具类等等。
一个很巧的机会朋友问我，现在代码生成器很多，你看能不能封装一个到框架里？我就试着去写了，Web UI以前也没用过，EasyUI据说不错就试着用它，写的过程中发现通用性很强，我就开始试着用模板语言去实现页面的生成。后来经过逐渐完善，慢慢推出了JEECG。
JEECG其实就是大家再熟悉不过的SSH2+EasyUI框架，只是经过了再封装，增加了代码生成器、表单校验自动生成、查询条件生成器、图形报表封装、常用共通封装的一些功能，目前封装的功能基本能满足一般项目的需求。
目前，工作流正在集成中……
JEECG的设计思想？采用的技术？
首先引几段前辈的话：
引用
- 十年前，这种代码生成工具的研发就非常火爆，但很快就灭了。因为软件不是家具。软件不在于它的一次性生产成本，而是变更及维护成本。
- 当年啊，用python吐出python代码到内存再执行python代码，一段时间后发现代码维护不了了，只能重新再写了一遍。
- 大量的代码生成不一定是好事。很多时候团队会被这类工具的限制受困。
根据前辈经验总结到一点：纯粹依赖代码生成器是不可行的，维护是个很大问题，所以
我借鉴前辈的经验，推出了代码生成+手工MERGE的半智能开发模式，即：
- 基础功能（常用数据模型的增删改查）由代码生成器生成使用，生成的代码可以随意修改；
- 复杂业务逻辑由开发自主实现，这样开发团队就不会受代码生成器的束缚，可灵活实现复杂业务，也能及时应对业务变化。
此外，JEECG采用主流的SSH2+EasyUI技术，生成的代码规范整洁，简单易懂，生成代码目录结构清晰，维护成本很低。
设计思想：
- JEECG采用主流架构技术，基于约定优于配置，采用命名规范实现零配置，整个项目action、service等自动扫描到Sring容器中；
- JEECG框架对代码生成器依赖性很低，可以完全脱离代码生成器使用（这种设计避免了开发团队被代码工具的束缚）。
采用技术：
- 架构技术：Struts2 + Spring3 + Hibernate4 + EasyUI1.3 + Spring JDBC + jQuery
- 开发环境：MyEclipse6.5 + jdk1.6 + Tomcat6.0
你如何看待这种（自动生成代码）开发模式？对开发者的利弊？
随着WEB UI 框架（EasyUI/jQuery UI/ExtJS/Dwz）等的逐渐成熟，系统界面逐渐实现统一化，代码生成器也可生成统一规范的界面！代码生成+手工MERGE半智能开发将是新的趋势，生成的代码可节省50%工作量，快速提高开发效率！！！
客观来说，JEECG 开发模式有利也有弊：
利：
- 让开发者从机械重复枯燥的工作脱离，更专注业务逻辑实现，提高了开发体验
- 提高了开发效率，实现了快速开发，缩短了项目周期
- 对于刚接触Java的人，也可以轻松基于该框架快速构建一套系统（只要会建表，通过表生成代码）
- 生成统一代码、统一规范、统一设计思路，便于维护
- 采用开源架构组合，解耦性强，可以完全脱离JEECG代码生成器，灵活自主开发（如果采用成熟智能化产品，项目开发就脱离不了智能开发工具，依赖性太大，变更及维护成本会很高）
弊：
- 对于开发新人来讲，弊处很多，开发新人正是锻炼编码能力的时候，代码自动生成弱化了开发人员的技能。
哪些代码可以通过JEECG自动生成？原理是什么？
JEECG代码生成器可以生成统一的前台页面、页面表单校验和规范的后台代码（Action、Service、Dao、Entity、Page等）。
JEECG代码生成器通过表生成代码，代码实现功能。即：读取表结构和字段属性，生成对应的实体、后台代码、前台页面、表单校验等。
JEECG代码生成的原理和方式：
- 是基于表来生成代码，针对有规则的表关系模型，生成对应的功能代码；
- 生成的代码无配置文件，遵循命名规范，基于约束大于配置零配置思想；
- 生成的action、service、entity、jsp页面等命名规范一致（采用驼峰写法），代码结构清晰也便于维护；
- 对于复杂业务逻辑，需要用户自己编码实现。这样就解决了复杂业务不断变化，智能化成熟产品难以适应业务不断变更，维护难的问题。
目前JEECG 代码生成器支持的数据模型：
- 单表数据模型
- 一对多表（父子表）数据模型
- 单表数据（自关联）模型
JEECG是你独立开发的，还是有一个团队？
目前JEECG是我一人，现在有很多朋友想加入，以后应该会逐渐成立团队。
该项目采用的开源协议？如果作为商业项目的基础开发框架，有什么限制？
JEECG 采用 Apache2.0 协议，对于商业使用没有什么限制。
对JEECG 感兴趣的朋友如何交流、反馈、参与贡献？
JEECG目前版本发布使用Google Code，地址：
http://code.google.com/p/jeecg/
SVN地址：svn://www.oksvn.com/jeecg-jbpm
JEECG已经开设技术论坛，对于JEECG 有好的建议或者发现BUG都可以去论坛发帖。
论坛地址：
http://www.jeecg.org/
此外，还可以通过QQ群（106259349、289782002）来交流、反馈。
未来的开发计划？
JEECG的未来发展路线主要是两个方向：
-
一个是实现JEECG代码生成器的工具化和通用性；
- 一个是继续封装当前框架，打造一个快速开发平台；
方向一：【JEECG代码生成器工具化设计方案】
目标：
-
JEECG代码生成器，抽离出框架，实现解耦设计Struts2、Spring MVC 、Hibernate、Mybatis、EasyUI、DWZ、ExtJS等技术灵活组合使用，导入JEECG JAR支持和模板即可生成对应的代码；
-
JEECG 模块支持用户自定义，类似QQ空间模板，用户按照JEECG 规则，即可自制不同风格模板。
使用方法：将jeecg-generate.jar 导入到项目中，载入JEECG 模板，即可通过工具类生成代码；
JEECG 产品模块预期功能说明：
|
jeecg-generate.jar 功能
|
- 支持不同数据库
-
读取表结构[字段属性]
- 根据模板生成代码；
设计原理：
-
jeecg-generate.jar，抽离出框架，做到兼容性友好
-
jeecg-generate.jar 实现解耦设计，实现Struts2、Spring mvc、Hibernate、Mybatis、EasyUI、Dwz、ExtJS等灵活组合使用
|
|
JEECG FTL模板
|
提供多套模板，针对不同架构技术，提供不同模板，例如：
-
Struts2+Spring+Hibernate+EasyUI；
-
Struts2+Spring+Mybatis+EasyUI；
- Spring mvc+Hibernate+Freemarker+Dwz
-
Spring mvc+Hibernate+Freemarker+ExtJS等
特点：模板支持用户自定义，只需要按照JEECG规则，即可自制不同风格模板
|
|
支持表关系模型
|
- 单表数据模型
- 自连接数据模型
- 一对多（父子表）数据模型
- 一对多数据模型中的一张表是自连接
- 多对多数据模型
- 多对多数据模型中的一张表是自连接
|
|
生成代码
|
生成内容：前台页面+表单校验（必输、数字、金额、时间控件） + 后台代码 + 后台校验 Acton\ServiceI\ServiceImpl\Page\Entity\Dao\Jsp
|
方向二：【JEECG 智能开发平台】
后续待完善的五点：
-
JEECG 生成器的进一步完善
- 工作流的封装
- 智能报表封装
- 查询过滤器封装
- 外围接口智能化封装
设计方案：
|
A
|
【生成器】代码生成器（代码一键生成），实现解藕设计，Struts2，spring mvc ，hibernate，mybatis灵活搭配使用
|
|
B
|
【生成器】代码生成器生成的页面，支持用户拖拽页面字段控件，重新布局
|
|
C
|
【工作流】业务流程采用工作流来实现
特点：保证了业务流程的灵活可变性，逻辑设计清晰，便于日志监控（业务流程变更，业务人员画下流程即可，既灵活又便于监控）
|
|
D
|
【工作流】在页面层实现画流程功能，让开发从流程工作脱离出来，支持用户自定义流程
|
|
E
|
【工作流】支持用户自定义表单
|
|
F
|
【报表】智能化报表工具封装
备注：开发不需要参与，业务员直接配置使用（只需写SQL）
|
|
G
|
【查询条件生成器】查询过滤规则进一步封装
备注：页面查询功能: 页面追加查询字段，后台不需写代码，查询条件自动实现完成
追加：大于小于等其他匹配方式；
进一步封装页面查询控件，针对每个匹配方式实现一个控件，让用户直接输入内容，不需要关心采用哪种匹配方式（即：封装匹配规则，增强用户体验）
|
|
H
|
【外围接口】WebService接口实现配置使用，方案：
- 使用唯一接口实现，传入传出采用报文方式实现
- 报文解析实现自动转换，传入传出报文格式定义实现可配置
- 接口校验自定义
说明：通过配置来实现一个接口功能，达到无需编码的目的
|
- 大小: 48.2 KB
- 大小: 128.8 KB
分享到：
您还没有登录,请您登录后再发表评论
82 楼 hjzhbb7758 2013-02-22 13:12
81 楼 zhangdaiscott 2013-02-18 16:16
hibernate 还是有不少公司不怎么用的。
JEECG[spring mvc +mybatis]版本已经整合完成，有需要的可以联系我！！！
80 楼 kmkim 2013-02-05 21:18
79 楼 zhangdaiscott 2013-02-03 09:18
你说的很对，我会慢慢往这个方向发展的，希望我还可以向你请教！！！
78 楼 killko 2013-02-03 04:37
77 楼 hxt1227 2013-02-02 09:31
hibernate 还是有不少公司不怎么用的。
嗯，你说的我想到了，我最理想的想法是针对每一套流行的框架出一套代码生成器模板，但是目前太忙，所以周期可能会长一些
可以参考rapid-framework,这个有很多模板了~
76 楼 zhangdaiscott 2013-01-30 14:07
hibernate 还是有不少公司不怎么用的。
嗯，你说的我想到了，我最理想的想法是针对每一套流行的框架出一套代码生成器模板，但是目前太忙，所以周期可能会长一些
75 楼 kingxip 2013-01-30 13:45
那些只会评价别人的人，不用理会，他们只是过客，让那些所谓的觉得别人框架多牛多好去吧，他们顶多只是用框架的人！！！
走自己的路，让别人越看越远吧...
不要激动。在这个框架泛滥的时代，不要期望随便出个框架就有人叫好。现在能成为主流的框架总有它的卓越之处，对这些框架全不去了解不去学习就埋头做自己的，能做出好框架的可能性很小。我身边的例子就有几个，我作为旁观者看得很清楚。
也不用为本框架的作者不平。也许作者在经过一、两年的学习后否定了自己，不再维护本框架了呢？又或者仍然开发、维护，但推翻了大部分的设计呢？这种情况是有可能发展成为好框架，但现在对其的批评没什么不妥。当然也有可能仍然认为现在的设计很好，没有需要从别的框架借鉴的东西。这种情况就很可能是个好框架。但批评对于督促作者学习、分析、对比仍是有意义的。
看你写的那么多，也是个有心人！人家作者一直没出来说话，你知道人家怎么想的？说不定是我们肤浅，人家的想法，不是你我从表面能猜到的！有些人也不用老摆着一个前辈的样子去批判人家，咱就说有几个人能写出来作者的这个东西吧，都说简单能写，但又有几个能真正静下来心来，真正写出来的？！！光这一点我就佩服作者，光以批判的眼睛去看别人，最好先想想自己又做出什么东西来...
这鸡蛋真难吃啊！
难吃？你去下一个好吃的蛋出来啊！
74 楼 atgoingguoat 2013-01-30 11:35
73 楼 atgoingguoat 2013-01-30 11:31
hibernate 还是有不少公司不怎么用的。
72 楼 flatcsun 2013-01-30 08:58
71 楼 zhangdaiscott 2013-01-29 23:48
还是要对作者说一声，加油,你做的很棒！
谢谢你的建议，等年前忙完，我会抽时间整理一下文档，再在录一套视频！
70 楼 zhangdaiscott 2013-01-29 23:46
scott人品不错，加油！哥们！
O(∩_∩)O~
69 楼 zhangdaiscott 2013-01-29 22:16
68 楼 wushexu 2013-01-29 21:56
那些只会评价别人的人，不用理会，他们只是过客，让那些所谓的觉得别人框架多牛多好去吧，他们顶多只是用框架的人！！！
走自己的路，让别人越看越远吧...
不要激动。在这个框架泛滥的时代，不要期望随便出个框架就有人叫好。现在能成为主流的框架总有它的卓越之处，对这些框架全不去了解不去学习就埋头做自己的，能做出好框架的可能性很小。我身边的例子就有几个，我作为旁观者看得很清楚。
也不用为本框架的作者不平。也许作者在经过一、两年的学习后否定了自己，不再维护本框架了呢？又或者仍然开发、维护，但推翻了大部分的设计呢？这种情况是有可能发展成为好框架，但现在对其的批评没什么不妥。当然也有可能仍然认为现在的设计很好，没有需要从别的框架借鉴的东西。这种情况就很可能是个好框架。但批评对于督促作者学习、分析、对比仍是有意义的。
看你写的那么多，也是个有心人！人家作者一直没出来说话，你知道人家怎么想的？说不定是我们肤浅，人家的想法，不是你我从表面能猜到的！有些人也不zzzzzz用老摆着一个前辈的样子去批判人家，咱就说有几个人能写出来作者的这个东西吧，都说简单能写，但又有几个能真正静下来心来，真正写出来的？！！光这一点我就佩服作者，光以批判的眼睛去看别人，最好先想想自己又做出什么东西来...
不用问这样的东西有几个人能写出来，毕竟不是人人都有意做框架。开发通用框架也不用觉得有多牛，在有的人看来框架代码跟别的代码没有什么不同。架构一个大型业务系统丝毫不比开发一套通用框架简单。对问题就事论事讨论而已，怕打击热情而避免争论没有必要。这点作者的心态比你好。事实上我也没开始批评呢。观点的碰撞本来就是激烈的，没有争论可能是大家都很正确，也可能是大家都很中庸。多年以前技术论坛是很火的，大佬多，讨论问题都很激烈的。现在不行了，没意思，牛人不愿来，说两句就急就更没劲了。
67 楼 fly1206 2013-01-29 20:09
那些只会评价别人的人，不用理会，他们只是过客，让那些所谓的觉得别人框架多牛多好去吧，他们顶多只是用框架的人！！！
走自己的路，让别人越看越远吧...
不要激动。在这个框架泛滥的时代，不要期望随便出个框架就有人叫好。现在能成为主流的框架总有它的卓越之处，对这些框架全不去了解不去学习就埋头做自己的，能做出好框架的可能性很小。我身边的例子就有几个，我作为旁观者看得很清楚。
也不用为本框架的作者不平。也许作者在经过一、两年的学习后否定了自己，不再维护本框架了呢？又或者仍然开发、维护，但推翻了大部分的设计呢？这种情况是有可能发展成为好框架，但现在对其的批评没什么不妥。当然也有可能仍然认为现在的设计很好，没有需要从别的框架借鉴的东西。这种情况就很可能是个好框架。但批评对于督促作者学习、分析、对比仍是有意义的。
看你写的那么多，也是个有心人！人家作者一直没出来说话，你知道人家怎么想的？说不定是我们肤浅，人家的想法，不是你我从表面能猜到的！有些人也不用老摆着一个前辈的样子去批判人家，咱就说有几个人能写出来作者的这个东西吧，都说简单能写，但又有几个能真正静下来心来，真正写出来的？！！光这一点我就佩服作者，光以批判的眼睛去看别人，最好先想想自己又做出什么东西来...
66 楼 fly1206 2013-01-29 20:08
那些只会评价别人的人，不用理会，他们只是过客，让那些所谓的觉得别人框架多牛多好去吧，他们顶多只是用框架的人！！！
走自己的路，让别人越看越远吧...
不要激动。在这个框架泛滥的时代，不要期望随便出个框架就有人叫好。现在能成为主流的框架总有它的卓越之处，对这些框架全不去了解不去学习就埋头做自己的，能做出好框架的可能性很小。我身边的例子就有几个，我作为旁观者看得很清楚。
也不用为本框架的作者不平。也许作者在经过一、两年的学习后否定了自己，不再维护本框架了呢？又或者仍然开发、维护，但推翻了大部分的设计呢？这种情况是有可能发展成为好框架，但现在对其的批评没什么不妥。当然也有可能仍然认为现在的设计很好，没有需要从别的框架借鉴的东西。这种情况就很可能是个好框架。但批评对于督促作者学习、分析、对比仍是有意义的。
...
65 楼 wushexu 2013-01-29 18:02
那些只会评价别人的人，不用理会，他们只是过客，让那些所谓的觉得别人框架多牛多好去吧，他们顶多只是用框架的人！！！
走自己的路，让别人越看越远吧...
不要激动。在这个框架泛滥的时代，不要期望随便出个框架就有人叫好。现在能成为主流的框架总有它的卓越之处，对这些框架全不去了解不去学习就埋头做自己的，能做出好框架的可能性很小。我身边的例子就有几个，我作为旁观者看得很清楚。
也不用为本框架的作者不平。也许作者在经过一、两年的学习后否定了自己，不再维护本框架了呢？又或者仍然开发、维护，但推翻了大部分的设计呢？这种情况是有可能发展成为好框架，但现在对其的批评没什么不妥。当然也有可能仍然认为现在的设计很好，没有需要从别的框架借鉴的东西。这种情况就很可能是个好框架。但批评对于督促作者学习、分析、对比仍是有意义的。
64 楼 tt360 2013-01-29 17:13
scott人品不错，加油！哥们！
63 楼 fly1206 2013-01-29 16:54
那些只会评价别人的人，不用理会，他们只是过客，让那些所谓的觉得别人框架多牛多好去吧，他们顶多只是用框架的人！！！
走自己的路，让别人越看越远吧...
62 楼 fly1206 2013-01-29 16:53
61 楼 fendoufx 2013-01-29 16:26
60 楼 X_zero 2013-01-29 11:47
59 楼 rimoer 2013-01-29 11:05
58 楼 wushexu 2013-01-29 09:35
我在5年前用过，国内外这种成熟的东西，太多了。
但都不能与业务，或者说动态表建立联系。
想问前辈，五年前到现在，你一直在采用手工MERGER+代码生成这种半智能开发模式吗？可能你比较资深，但是对我参加工作这么久，公司一直以来都是没有这一块东西（后台代码只有雏形生成，能结合页面生成的没有）
我说几句作者会不高兴的话。
自从几年前我熟悉了rails，就对别的web框架毫无兴趣（当然rails不只是web框架）。rails的创新很多，一直都在引领潮流。很难想象现在的web框架作者不了解rails。
另外代码生成是比较低级的东西，如果知道怎么生成，再智能一点，就会知道怎么隐藏起来。举个例子，rails的ActiveRecord有很多代码生成，但它是在运行时生成的，开发者没必要看见。
57 楼 zhangdaiscott 2013-01-28 21:53
我在5年前用过，国内外这种成熟的东西，太多了。
但都不能与业务，或者说动态表建立联系。
想问前辈，五年前到现在，你一直在采用手工MERGER+代码生成这种半智能开发模式吗？可能你比较资深，但是对我参加工作这么久，公司一直以来都是没有这一块东西（后台代码只有雏形生成，能结合页面生成的没有）
56 楼 atgoingguoat 2013-01-28 16:58
我在5年前用过，国内外这种成熟的东西，太多了。
但都不能与业务，或者说动态表建立联系。
55 楼 sunlongan666 2013-01-25 20:48
还是要对作者说一声，加油,你做的很棒！
54 楼 y5092_2012 2013-01-25 17:29
53 楼 zhangdaiscott 2013-01-25 17:25
首先代码生成器写的不错，代码生成可以直接使用，确实方便 ,不过页面下拉组件需要自己实现;
其次查询的封装也很不错(各种匹配方式)，说明作者很有想法,前台页面追加查询字段，后台自动封装成SQL，省去不少麻烦。这两项已经很大程度上提高了开发效率，其他工具类的封装暂时还没用...
一句话吧，这是一个很实用的框架，不过还需要继续完善，支持你，非常期待你在未来开发计划中的构想。。。
非常感谢一个朋友的心得！