开源项目G4Studio远景战略抉择！请大家指路

关于开源项目eRedG4的相关信息请大家浏览这个新闻贴，我这里就不再赘述了。
这里就简单说一句便于后面的讨论.eRedG4相关主要技术选型：ExtJS3.X+Struts1.X+Spring2.X+iBatis2.X。

（批注：下一版本可能精简为：Ext3.X+Spring2.X+iBatis2.X）

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

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

 

今天讨论的主题在这里：

目前，G4下一步要解决的重点是如何在保证性能的前提下：

(1). 降低项目组学习培训成本。

(2). 降低项目开发成本以及提升项目后期的可维护性。

最终实现行业应用二次快速开发的目标。

 

我现在有2套方案：

方案一. 将EXTJS标签化，使用G4模板引擎动态生成ExtJS字符流通过JSPTag输出响应。使用Eclipse-Plugin技术生成iBatis的SQL单表CRUD映射文件以及数据持久化对象或者说是实体领域对象。

优势：

a). 标签化封装简单，偶轻车熟路。很短的开发周期将完成EXtJS全套UI组件标签化。
b). JspTag对开发人员能力要求较低，简单培训后项目组成员便可以上手开发，降低了学习培训成本，提高了开发效率。

c). JspTag后期维护叫ExtJS代码而言相对比较方便。

缺陷和不足：

a). JspTag运行时动态生成EXTJS代码增加了Web服务器的计算成本，增加了CPU、内存资源开销以及网络带宽开销。是否会在UI性能方面产生瓶颈没有确实的经验。

b). 不利于做一些静态JS资源的压缩和缓存处理，给从这个角度出发的性能调优带来困难和障碍。

c). 这种实现方式实在没啥靓点。

方案二. 使用Eclipse-Plugin技术实现一个ExtUI可视化正向代码生成和逆向修改的UI设计器;生成iBatis的SQL单表CRUD映射文件以及数据持久化对象或者说是实体领域对象。

优势：

a). 对开发人员能力要求较低，简单培训后项目组成员便可以上手开发，降低了学习培训成本，提高了开发效率。

b). 编译时生成原生EXTJS，可以方便的在运行时对其进行压缩和缓存处理。教标签化而言Web服务器压力计算成本、CPU资源、内存资源、网络传输开销成本都不同程度的降低。

c). 实现方式比JspTag有吸引力，便于宣传推广更迅速的被大众接受和大家分享这个开源项目。

d). 此种实现方式其技术积累可以持续性发展，为后期的工作流设计器乃至打造一个综合集成的兼顾前后台开发关键任务G4IDE奠定基础。

缺陷和不足：

a). 实现可视化正向逆向UI设计器相对技术要求较JspTag实现要高，开发周期会很长。

b). 如果ExtUI设计器逆向功能实现得不好，将会对以后得维护工作带来不便。及时逆向UI修改功能实现得很好，以后ExtJS的升级也会给以前设计好的界面在新的UI设计器器上的逆向维护带来些许麻烦。

 

对上面2中方案其实我已经纠结很长时间了，只是现在到了必须做出抉择的时候。所以发出来请大家看看有什么意见和建议或者指出偶分析得不对的地方。亦或有更好的实现方式。望大家不吝指教...

 

 

评论

20 楼 yin_bp 2011-09-25  

春哥搞一套Ext3.X+bbossgroups的方案如何啊

19 楼 fnet 2011-03-15  

春哥，搞一套springmvc版本啊，现在流行啊！

18 楼 toeo 2011-03-15  

我自己 也在弄extjs

我是用的 extjs 2.0 + struts2 + hibernate3 + spring3

我貌似也在和 LZ  做同样的事情。只不过 没有楼主做 的那么厉害。

我的思路简单。

我是另外一种实现。将ext2.0封装成 jsp的标签。

让标签生成html 组织成页面。没有用到extjs的js部分用到了样式。

而需要写的js用jquery实现。页面组织还是 用的嵌套 iframe的形式。

我想服务器快就行不用全部都是ajax。用标签的话好修改维护成本也不高。

现在我考虑的是用这些东西实际做点管理后台的程序。能组织成项目并且简单维护就行。

我很在意 extjs的开源政策所以用的2.0 的版本。


http://toeo.iteye.com/admin/blogs/830351

17 楼 huang_yong 2011-01-17  

eredlab，你好！

最近无意中看到你开发的这套系统，我这人说话比较直接，说的不好，请不要往心里去。

一、从整体上来看，系统做的非常不错，十分专业，考虑的问题也非常细致。我所理解的目前定位是，类似于向其他开发商提供二次开发的工具，但现在还是得使用传统的 ExtJS 来开发，需要一定的学习时间才能灵活运用。

二、方案一：如果说将常用功能做成 JSP 标签，一定会对性能打很大折扣，不过如果开发后台系统，用户对这一点还是可以忍受的。

三、方案二：如果使用代码生成技术，并且通过图形化用户界面来进行开发，如果做得好，确实可以提高不少开发效率，但是相反，如果做得很难用，那到不如不做。：）

四、个人建议：使用方案一的风险性比方案二要高很多。如果这套系统只是面向后台管理系统而言，个人觉得在性能方面可以不用特别在意，在后端实现缓存，将减小查询数据库的开销，这样也势必也节省了一些性能。推荐使用方案一。

五、其它建议：不妨对各个常用组件提供一个简易配置的功能，用户只通过图形化配置，就可生成 ExtJS 代码，然后把这些生成的代码，复制到自己的代码中即可，这样可减少用户（程序员）写代码所带来的时间开销。也就是说，我建议作者开发一个 ExtJS 的图形化代码生成器。

PS：上海某公司（实在不方便透露）做了一个类似方案二的项目，已经投入商用，但据了解，效果并不理想。

16 楼 zhangyou1010 2011-01-05  

引用

ExtJS3.X+Struts1.X+Spring2.X+iBatis2.X。

疑问: 为啥不用struts2，而用struts1呢？

15 楼 flyfan 2011-01-04  

标签化没必要，封装一下Ext还好

14 楼 eredlab 2011-01-04  

kkqqcom 写道

nazca已经实现了方案2。

似乎又是挂羊头卖狗肉。没看到源码。非常不厚道。哎。。不放代码就别说自己是开源。不过图片上看到的效果确实不错。和偶方案二计划要实现的东西相差无几，没人开等的偶来开吧！！

13 楼 kkqqcom 2011-01-04  

nazca已经实现了方案2。

12 楼 cgs1999 2011-01-04  

aronlulu 写道

方案一走tapestry，jsf，Gwt的路子，拿一种语言生成另一种语言，性能好不到哪去，还不如将ext二次封装。
方案二EXT设计器做得牛逼一点还行，参考FLEX的设计器，不然基本也是无人用，只能给新手拿来当做EXT的入门代码参考，实际开发不会有人用，因为拖拽自动生成的代码不可能非常OO化，还是要自己排版重写，即使flex也是如此，实际开发很少用设计器了。
所以还是建议将EXT做丰富化的二次封装和扩展，多提供点模板，高级应用参考，走类似springside的路子，本质上还是提供EXT简易化开发。

个人认为两种方案都不是很好，同楼上
1）方案一可以采用相关的模板技术实现（官方有gwt-ext）；
2）方案二所提的设计器主要是提高界面的工作效率，工作量很大，后期的维护升级都会是比较麻烦；

建议：
1）可以考虑类似于项目模板的开发方向；
2）可以考虑类似于提供项目整体解决方案的方向，即：分界面解决方案和底层解决方案，两层之间采用json或xml的方式进行交互，这样开发人员可根据需要选择不同的解决方案或两套解决方案；
3）另项目可结合模板技术，可自带默认模板，开发人员也可自行定义；

11 楼 aronlulu 2011-01-04  

方案一走tapestry，jsf，Gwt的路子，拿一种语言生成另一种语言，性能好不到哪去，还不如将ext二次封装。
方案二EXT设计器做得牛逼一点还行，参考FLEX的设计器，不然基本也是无人用，只能给新手拿来当做EXT的入门代码参考，实际开发不会有人用，因为拖拽自动生成的代码不可能非常OO化，还是要自己排版重写，即使flex也是如此，实际开发很少用设计器了。
所以还是建议将EXT做丰富化的二次封装和扩展，多提供点模板，高级应用参考，走类似springside的路子，本质上还是提供EXT简易化开发。

10 楼 KimHo 2011-01-03  

个人更喜欢方案二
可以借鉴下微软的asp。net设计思路，前台直接拖控件，后台直接看代码:code-behind设计思路。
系统架构方面，利用ext3.0的Ext.Direct特性，是可以抛弃struts这层了。ibatis还是离不开sql的书写，建议直接hibernate吧，更利于新项目的快速开发。

9 楼 bugu1986 2011-01-03  

ExtJS开发也不是很复杂啊。另外楼主想没想到如果您的实现有bug咋办。方案一是不是有点像JSF的意思，在服务器端解决客户端的问题？客户端的问题就让js解决挺好的，您说是不，我js写的时间不长，可是一点没觉得extjs难啊。
方案二，还不错，不过确实蛮难实现的。不过birt那个报表软件生成器是不是跟您这个想法有点像？不过就像您说的，维护又是问题，调试也还好，毕竟能看到extjs的代码

8 楼 eredlab 2011-01-03  

ini_always 写道

实际上我一直没明白这个是干嘛的，楼主勿怪。。。

呵呵，不奇怪，非常正常。

7 楼 eredlab 2011-01-03  

iamlipeng 写道

方案一的前两个“缺陷和不足”比较致命，不建议使用方案一。
对于方案二，其实ExtUI设计器不是很重要，关键是编译时生成原生EXTJS，这点很重要。

那照你的逻辑，就是说UI设计器不实现逆向修改并不重要喽。主要是正向代码生成。但这有个问题就是说：如果生成页面后，有些微调就得需要程序员手工调整。包括以后的维护也要手工调整。这就得要求程序员实际上也需要熟知Ext才行。这就没从根本上解决Ext UI开发复杂性的问题。但或许也是个折中办法。实现一个成熟稳定的UI正向反向设计器代价还是优点大

6 楼 ini_always 2011-01-03  

实际上我一直没明白这个是干嘛的，楼主勿怪。。。

5 楼 iamlipeng 2011-01-03  

方案一的前两个“缺陷和不足”比较致命，不建议使用方案一。
对于方案二，其实ExtUI设计器不是很重要，关键是编译时生成原生EXTJS，这点很重要。

4 楼 lgcpeter 2011-01-03  

希望能有机会用ERed开发一个应用。

3 楼 lgcpeter 2011-01-03  

我觉得：
基础工具和框架很重要，但最好要有几个真实的应用案例，能让开发者很直接的看到应用这个得到便利和实惠。
另外简单很重要，定义的规则逻辑性好，能够由一个简单的概念起步最好。
你的第一套方案就可以，html挺复杂，但基本的标签定义的很清楚，手写反而比用工具更好。关键还是标签的抽象上下工夫。

2 楼 eredlab 2011-01-02  

KimShen 写道

我从Lz眼中看到的浮躁

。。。偶很淡定。你眼神不怎么好。

1 楼 KimShen 2011-01-02  

我从Lz眼中看到的浮躁