开源平台G4Studio_V1.03.1发布了

 

做最厚道的开源项目-将开源进行到底！

简介：

G4Studio(易道系统集成与应用开发平台)是一个开放源代码的、面向企业计算环境下异构系统集成与行业应用快速二次开发的平台。它包括：基础类库、业务模型框架、富浏览器端开发框架、富桌面端开发框架、权限参考模型、平台代码生成器六大组成部分。

 

 

GoogleCode项目主页:
http://code.google.com/p/g4-xiongchun

在线演示系统
http://web230531.host89.chinajsp.net

eRedG4成长日志

2010-12-22 发布eRedG4_V1.03.1版本

(1). 修复了系统管理下面所有功能分页的Bug.(此Bug由V1.03版本简化DAO开始模式,重写系统够后台时候引起)

(2). 修复了人员授权后登录系统求权限并集的Bug.(此Bug由V1.03版本简化DAO开始模式,重写系统够后台时候引起)

(3). 修复了封装的mysql分页算法翻页时候每页记录数翻倍的BUG.

 2010-12-20 发布eRedG4_V1.03版本

(1). 实现了服务器不相关的静态资源管理器(G4.Resource),对CSS/JS文件进行压缩和缓存处理。

(2). 基于G4.Resource对在线演示系统进行升级,完成在线演示系统的二次提速.效果很给力！

(3). 完善序列号反生器组件(G4.ID)在高并发下的线程同步隐患问题。

(4). 以G4最终定位的简化Dao开发模式的思想,重写G4初期实现的权限参考模型的后台代码。

(5). 解决系统管理模块中MYSQL不兼容Oracle的sysdate关键字而引起的bug。

(6). 重新规划了业务模型层的命名规则并对现有代码做了相应调整。

(7). 对配置文件目录结构做了微调。

(8). 废除了领域实体对象Domain的概念，引入持久化对象PO和值对象VO的概念。

(9). 修复在MYSQL5.5版本下maxvalue被作为保留字导致G4出错的Bug。

2010-12-15 发布eRedG4_V1.02版本

(1). 完善了JDBC监控的控制台输出模式。

(2). 解决了index.js中由于网络慢Dom元素未产生而提前执行获取Dom方法的Bug。

(3). 购买了虚拟主机部署了eRedG4演示站点。

(5). 解决非developer帐户登录查询基于用户授权的菜单权限信息SQL语句的Bug。

(6). 解决了EAHTTPSESSION表在Tomcat中启动sessionid由于字段长度不够而报错的Bug。

(7). 对监控功能加入了演示运行模式控制。

(8). 编写了《搭建G4开发环境.chm》文档；重新录制了《视频教程:搭建基于eRedG4_V1.*的开发环境》。

2010-12-12 发布eRedG4_V1.01版本

(1). 全面支持了Mysql。系统管理及所有的Demo都能做Mysql上运行，并封装了Mysql分页算法。对用户提供了和Oracle一致的分页API编程接口。完全屏蔽MYQL和Oracle的底层数据库分页算法差异。

(2). 修复了系统管理功能中的表格翻页丢失查询参数的Bug。

(3). 美化了系统管理菜单图标及调整了菜单排列。

(4). 完善了一些系统管理后台代码和标准范例代码。

(5). 测试了G4在JDK1.5环境下的兼容性,一切OK!

(6). 完善了Oracle SQL脚本和DMP、新增了MYSQl数据初始化脚本.

(7). 重新录制了基于G4V1.01版本创建G4开发环境的视频教程。

2010-12-08 发布eRedG4_V1.0版本

(从2007-10到2010-12-08,G4经历了漫长的辛酸捣腾史,终于发布V1.0版本了!)

(1). 定义并封装G4常用数据结构：DTO、KEY、PO、VO。

(2). 实现数据库无关的支持集群部署的支持ID缓存的序列号发生器。

(3). 实现G4默认的AJAX交互资料格式JSON的Java编码与解析的Json处理器。

(4). 实现对属性文件进行常规CRUD操作的工具类封装。

(5). 汇编了大量的开发实用工具类G4Utils。

(6). 实现了G4异构系统缺省交互资料格式XML编码与解析的XML处理器。

(7). 实现了基于Velocity封装的模板引擎。

(8). 完成Struts-Spring-iBatsi的框架集成。

(9). 完成对Action、Service和DAO的基类抽象定义。

(10). 实现基于jetty的内置式开发调试服务器G4Server的封装。

(11). 完成<eRedUI:arm.Viewport />、<eRedUI:html />、<eRedUI:body />、<eRedUI:import />、<eRedUI:div />、<eRedUI:script />、<eRedUI:out />、<eRedUI:flashReport />、<eRedUI:ext.codeStore/>、<eRedUI:ext.codeRender />...等标签的封装。

(12). 完成对FusionChartsFree图形报表的标签化封装和数据填充API封装。

(13). 完成对Jasperreport报表引擎的封装，支持Applet打印和PDF打印及导出。

(14). 完成对Excel模板自定义标记语言定义及相关封装，实现基于自定义模板标记语言的Excel导出。

(15). 完成权限参考模型的设计及实现。包括:组织机构管理、角色管理与授权、人员管理与授权、菜单资源管理。

(16). 完成基础数据维护模块的设计与实现。包括：字典维护、全局参数表维护、异常信息维护。

(17). 完成运行监控模块的设计、底层封装与实现。包括：Request请求跟踪、Session会话监控、JDBC执行监控、SpringBean监控。

(18). 完成开发小助手模块的实现。包括:ExtJSAPI速查、调色板、系统与之图标功能。

(19). 抽象定义了"G4ESB"简单参考模型，并完成了Webservice和HttpInvoker两种远程服务开发模式的封装与集成。

(20). 反复论证G4是将Ext进行标签化封装还是使用原生ExtJS进行简单扩展，最终提供G4.Builder来支持快速开发。论证结果：选择后者。

(21). 完成表单及表单元素标准范例开发。包括：基本输入(属性配置)、基本输入(方法事件)、日历选择框(日期时间)、下拉选择框(本地数据源)、下拉选择框 (字典数据源)、下拉选择框(远程数据源)、下拉选择框(N级联动)、单选框复选框、表单交互(提交、填充)、工具栏菜单栏、消息对话框、富文本输入框、 Form布局(缺省)、Column布局、综合布局1、综合布局2。

(22). 完成窗口及面板组件标准范例开发。包括：面板范例1、窗口范例1、Tab标签卡范例1。

(23). 完成表格组件标准范例开发。包括：表格范例1(基本特性)、表格范例2(行级展开)、表格范例3(可编辑表格)、表格范例4(列锁定)、表格范例5(缓冲表格)、表格范例6(合计表格)。

(24). 完成树形组件标准范例开发。包括：树范例1(普通树)、树范例2(异步树)、树范例3(复选树)、树范例4(级联复选树)、树范例5(下拉树)、树范例6(异步表格树)。

(25). 完成报表组件的标准范例开发。包括：Applet报表、PDF报表、Excel导出、Excel导入。

(26). 完成图表组件标准范例开发。包括：2D|3D柱状图、2D|3D饼图、2D|3D柱状组合图、折线图、折现组合图、面积图、面积组合图、漏斗图、环状图、2D|3D折现柱状交叉图、交互图(JS调用、下钻、超链接)

(27). 完成页面布局组件标准范例开发。包括：Viewport自适应布局、Viewport嵌套复杂布局。

(28). 完成综合实例标准范例开发。包括：综合范例1、综合范例2、综合范例3、综合范例4、综合范例5、综合范例6。

(29). 完成对JasperReport-Applet打印功能的数字签名。

(30). 实现系统换肤功能。

刚刚看了一下演示系统，发现在操作树的控件时，出现点击前面的节点图标时，有时会将复选框给同时操作了（选中或取消）

优势一大侠啊!!!这个一定要好好来学习下

很炫
效果很好！

等你很久了.

观摩一下.

是肯定的了.

dto 这样设计好吗？
所有的VO，BO都以一个HASHMAP的形式存放，
开发时速度是提高不少，不用管BO，VO，PO之间的转换。但这些都是建立在自己知道数据规则的情况下的。

如果在多人分层开发时，不同层的人看到的多是一个HASHMAP，具体里面是什么数据，数据是什么格式，他得DEBUG进去才知道;
或者这个开发任务交给下个人时，下个人就不知道这HASHMAP里具体会放什么数据了，没准哪个层做特殊处理在HASHMAP里放了个值，下个接手人不可能马上知道，最多是在系统出现异常才会发现

没错，如果注释不好的话，一个业务方法传参是用Map，结果参数一大堆，不知道哪更哪，维护起来很不方便。

没看懂你们的意思。我解释一下G4中对DTO PO VO 这些东东的约束和定义：
从广义上来说：PO VO也属于DTO范畴，但在G4中，我将PO VO DTO 定义为平级统一层面的东西。
DTO(数据传输对象)：对Map的一个包装，里面实现一些常用的类型转换方法，以及DTO到PO、VO和XML、JSON的转换。
PO(数据持久化对象)：指和库表结构字段一一对应的实体领域对象。此类一半由G4.Builder自动生成。不需要再做任何维护。
VO(简单值对象)：值在开发过程中可能会使用到的一些简单JavaBean。在G4实际项目中一般使用PO和DTO来做数据分层之间的传输。但一些特殊情况也需要用到VO。

在一个方法里传进去的值是一种格式BaseDto，传出来的又是另一种格式BaseDto，但始终都是一个HASHMAP，（这就像有些数据库设计的人，把所有的字段都用CHAR来表示一样，开发起来方便，不需要考虑太多。不过我自己感觉这样是不合理的）
对于从最外层到最底层都一个人开发，已经熟悉数据的规则，也知道自己创造出来的潜规则，怎么避开这个潜规则，不需要VO，BO，PO等间的转换,所以开发起来也很容易，

在同一个服务里，比如UserServiceImpl服务，
创建用户(saveUserItem)，删除用户(deleteUserItems)，更新用户(updateUserItem),查询用户(queryUsersForManage)，
传入的都是Dto对像，传出来的还是Dto对像，
对于开发这个UserServiceImpl服务的人，
当然知道在saveUserItem，updateUserItem传入的是一个带有字段属性的键值对对像就可以了，
deleteUserItems传入一个含有“strChecked"键的DTO就可以了，对应的值的格式是一个以逗号隔开的数据库主键值id就能够正常执行该方法了


但对于从业务层使用这个服务的另一个人，或者接手该任务的人，再或者经过一段比较长的时间，因为没有详细看ServiceImpl实现代码或通过DEBUG调试监控变量的值，所以不太可能知道在这4个方法里传入的DTOHASHMAP是什么格式的
（一个特定的字符串？一个特定的Bean?，还是一个其他什么特定的格式）,
返回的DTO对像又是一个怎么样的DTOHASHMAP
（是跟刚传进去的DTO一样格式的对像，还是要查看的数据库对应的一条记录的键值对，还是带有JSON格式的数据呢？还是其他什么格式）




像这样不管传入的参数还是返回的参数都是一个HASHMAP，没有了BO，VO，PO间的转换
如果在系统里只是一两次，写几个注释可能能避免使用的人不出错误，

不过使用多了就也可能产生这样的效果：
1.在一个比较大的业务系统上，可能会出现只有开发自己模块的人知道自己写的服务传入或返回的HASHMAP是什么格式，下一个接手人就只能通过DEBUG查看变量里的值才知道这个BASEDTO里面是什么内容
2.同一个人可能在这个UserServiceImpl的deleteUserItems方法里传入的是规定这种格式的数据{strChecked:["1,2,3,4"]},
但在GroupServiceImpl的deleteGroupItems方法里传入的是规定这种格式的数据{deleteids:["1,2,3,4"]},
格式没法统一定义，格式一多，很容易混乱。
3.接口的定义对方法传入参数及返回参数已经没有了意义，因为传入的是一个HASHMAP，在这个HASHMAP里自己可以定义自己想要的规则，一个即负责业务层又负责服务层的人，可能会把REQUEST对像放到这个HASHMAP里，这样直接在服务层操作Request对像，
返回的HASHMAP格式也可以自己去定义
4.整个系统很容易全部耦合在一起，就失去分层的做用了，

像这样的代码

public Dto queryUsersForManage(Dto pDto) {。。。

返回数据是这样一种格式

outDto.put("jsonString", JsonHelper.encodeJson2PageJson(jsonString, pageCount));

感觉这个就跟表现层耦合在一起了，如果我不要JSON格式，我需要一个手机WAP端的格式那该如何处理呢？(自己再写一个方法?或者在DTOHASHMAP里再放个wapString)
返回的数据格式应该是在Action层要返回到页面时自己处理一下要返回成什么格式(json),而在这个服务层里，就直接返回一个数组VO


或者这样说，我的这个ACTION（A）需要的是返回的一种jsonString（A）格式，
但可能还有另一个ACTION（B）也需要取得用户列表，返回的jsonString（B）格式跟queryUsersForManage是不一样的，那又该如何处理
(再往DTOHASHMAP里放一个？我有10ACTION需要10种不同格式的JSONSTRIGN，就往DTOHASHMAP里放10个不同的jsonString?)

楼上分析得很精辟啊。受益了！
G4里有一部分代码在Service里面进行了toJson的转换，的确从分层逻辑和业务服务组件复用的角度来看。确实不太妥当。这个会在下个春节版本V1.1中一起修正吧。很感谢你的建议。
但楼上下面几个观点偶也有自己的一些想法和大家交流：

 

 

首先一个大的系统，其设计和代码实现大多是遵循正统规范来执行的。就是说在你进行代码实现之前，每个方法，每个服务。层与层之间调用 方法传递的参数比如查询条件，返回的值等等都是已经形成了正式的设计报告的。代码实现仅仅是照着翻译一遍而已。不存在说不知道Dto里面放了些什么东西的说法。
其次：在一些小项目或者是不遵循正统规范的项目，比如一个根据人员编号查询此人员拥有的菜单权限的方法，除了当时的代码实现人员还有谁会去关注方法入参Dto里面是什么东西，出参dto里面又是什么东西呢？当然，如果你要说以后的程序整改人员想知道，那就看代码呀。不可能因为这一个需求或者说是很小的需求而去做因小失大的事情。你买电脑也讲个性价比的嘛。

 

 这个也不敢苟同。因为这个服务不是一个暴露的远程服务，不是一个需要第三方来调用消费的服务，所以我只需要知道这个东西是个数组就OK，至于说这个数组在DTO中的键是什么，那完全由当时的代码实现人员而定。在这个地方规定给程序员，好，你们在界面上复选得到的ID必须以“deleteids”之类的在DTO中存储，显然没必要。

 

 这是设计与实用之间折衷平衡的问题。显然，request，session之类对象肯定是通过一些比如G4开发规范之类的约束不建议或者说不允许将其传入到Service来操作的。但是比如,iBatsi的API，在G4中不但耦合到了Service，而且还耦合到了Action(仅仅是查询事物不相关的操作)，这就是一个简化DAO开发模式，在设计与实用快速之间的一个折中和平衡。这里如果强行按照设计和分层原作来做的话。那完全可以独立一个DAO层出来，所有的数据持久化和访问操作在这一层来完成，由Service调用这一层，将持久化框架iBatis的API完全的隔离在DAO这一个层面，但这样在实际开发中其效果如何呢？是否是一种过度设计的做法？能达到快速开发的效果吗？其性价比如何？我们付出了很多，但是得到的是什么？

 

 这个也就是刚才上面所属的设计与实用之间的一个这种权衡的问题。

 

总结：上楼的大哥的确有想法，提了一些建设性意见。再次感谢。偶把此贴转到G4社区去备个案吧。：）