|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-08-10
虽然已经对企业应用表示无聊了，但是对楼主的精神表示钦佩，加个良好。
持之以恒本身就值得所有程序员学习了。 |
| 返回顶楼 | |
|
发表时间：2010-08-10
sky3380 写道 桌面客户端建议用swing，一是跨平台方面好，二不用引入额外的包，三swing的性能随着JDK的升级也不断的提升，已经不是以前的swing了
说说跨平台：基于EclipseRCP技术的Java桌面客户端一样的跨平台，只要针对不同的平台打包就是了，确切的是应该是源代码跨平台。是write once run anywhere 而不是build once run anywhere。稍逊于Swing，但这无所谓的啦，客户端跨平台的需求在行业业务系统中很少有吧，即使有也无所谓打包一下就OK。再说说性能：SWT的性能是Swing天生就追不上的，再升级也没用。Swt通过JNI调用宿主目标主机的窗口部件，宿主没有的部件才自己去绘制。性能方面是完胜Swing的。这个大家感觉一下NB和eclipse就有体会了。最后说说EclipseRCP，自从Eclipse3.0版本以后，eclipse插件就可以脱离eclipse环境独立运行。也就是所谓的RCP了。她天生继承了eclipse自身的更新、帮助等机制尤其是插件机制。连帮助文档都是插件。我想把这种插件机制在行业应用业务系统中做一些尝试。虽然NB也提供了类似的RCP开发，但是继eclipse之后吧，成熟度可能不如EclipseRCP。而且NB是基于Swing图形库的。JasperReport的报表模板绘制工具iReport从3.0就是基于NBRCP模式开发的。用起来效果不咋的，没eclipseRCP的酷~~~~~~ |
| 返回顶楼 | |
|
发表时间：2010-08-10
精神值得学习.
|
| 返回顶楼 | |
|
发表时间：2010-08-10
最后修改：2010-08-10
引用 看的出来，g4是作者的呕心力作，不管是架构设计，技术选型还是细到代码编写，作者都反复推敲，g4乃开源上品.
感觉g4定位有点大，搞的太辛苦了，还不一定讨好，我建议将重心放到权限系统，界面容器和组织机构管理这种系统上来，提供java,c#等主流开发语言的API，这样对项目使用的的技术框架不做约束。 为坚持喝彩，注意劳逸结合，身体才是革命的本钱.作者好样的 感谢你的高度评价。但你的建议对偶现在的情形可以说是釜底抽薪，你说的那个可以单独立项了。偶现在只能是背水一战，永往之前了! 引用 logo 看起来有点山寨
哈哈，这都被你看出来了！Logo是山寨了已逝去的BEA的图标。 引用 开源地址什么时候出来！
我不是说了嘛 2011.09.21 还早呢 哈哈 我累了，速度放慢点！ 引用 是楼主自己在用还是楼主的公司在用，这个东东不好推广
公司有专门的平台研发组的。偶做这个主要是兴趣使然，准备开源发布的。希望是越多人来用越好！不好推广是什么意思。。楼上推广过类似的东东？？ |
| 返回顶楼 | |
|
发表时间：2010-08-10
要是能共享源代码，那就爽。。。
|
| 返回顶楼 | |
|
发表时间：2010-08-10
eredlab 写道 sky3380 写道 桌面客户端建议用swing，一是跨平台方面好，二不用引入额外的包，三swing的性能随着JDK的升级也不断的提升，已经不是以前的swing了
说说跨平台：基于EclipseRCP技术的Java桌面客户端一样的跨平台，只要针对不同的平台打包就是了，确切的是应该是源代码跨平台。是write once run anywhere 而不是build once run anywhere。稍逊于Swing，但这无所谓的啦，客户端跨平台的需求在行业业务系统中很少有吧，即使有也无所谓打包一下就OK。再说说性能：SWT的性能是Swing天生就追不上的，再升级也没用。Swt通过JNI调用宿主目标主机的窗口部件，宿主没有的部件才自己去绘制。性能方面是完胜Swing的。这个大家感觉一下NB和eclipse就有体会了。最后说说EclipseRCP，自从Eclipse3.0版本以后，eclipse插件就可以脱离eclipse环境独立运行。也就是所谓的RCP了。她天生继承了eclipse自身的更新、帮助等机制尤其是插件机制。连帮助文档都是插件。我想把这种插件机制在行业应用业务系统中做一些尝试。虽然NB也提供了类似的RCP开发，但是继eclipse之后吧，成熟度可能不如EclipseRCP。而且NB是基于Swing图形库的。JasperReport的报表模板绘制工具iReport从3.0就是基于NBRCP模式开发的。用起来效果不咋的，没eclipseRCP的酷~~~~~~ swt的性能只是在windows下才有一点优势，而linux下swing比在windows下快的多，你到linux下试一下NB就知道了。 |
| 返回顶楼 | |
|
发表时间：2010-08-10
楼主很有毅力，相信你会成功的，不过这名字。。。
实在有点。。。 易道。。 有道。。 道。。。 |
| 返回顶楼 | |
|
发表时间：2010-08-10
引用 swt的性能只是在windows下才有一点优势，而linux下swing比在windows下快的多，你到linux下试一下NB就知道了。
在Ubuntu下面用过eclipse，和Windows没啥区别嘛。NB没试过。。。因为一直不喜欢用那个IDE 可能是eclipse先入为主吧 |
| 返回顶楼 | |
|
发表时间：2010-08-10
贊一個，我也曾試著造過輪子，可惜也是夭折了。很難堅持！
我想接下來，應該在健壯性和擴展性上下工夫。 期待開源。 |
| 返回顶楼 | |
|
发表时间：2010-08-10
楼主，我觉得这不是制造一个重复的轮子，而是提供多一种选择，虽然每个公司确实都会有类似的架子存在，但是对于那些没有经过沉淀的新公司或是小公司来说，确实会有很大的帮助。
毕竟都需要一个重头开始的过程。 我以前的公司也有过类似的实现，我有了很长一段业余的时间才将其消化清楚，最近跳槽到另一家较新的公司，也有这样的设想，正在考虑熟悉业务之后做一个类似的实现。 所以我觉得至少楼主的东东对我有很大的帮助，赞一个。呵呵，期待你的大作！ （1）、基础类库 1)、常用数据结构，建议加上一个VO的超类，使用反射来定义get与set方法，通过传入参数进行属性的注入与获取，Apache下游线程的utils，并定义主键，主子vo规范等 2)、XML处理器，这个jdk1.5里好像支持得很不错了...vo与xml的相互转换....不过如果能够有更简洁好用的接口..当然也值得期待... 3)、JSON处理器，是否包含vo与json的相互转换？我觉得json与vo的相互转换应该放在父类中自动进行... 5)、模板引擎，不清楚具体的定义 （2）、业务模型框架(eRedBMF) 2)、基于iBatis2.X的数据持久化方案(已实现)，我觉得还是适当的支持hibernate，至少我有这方面的需求（客户要求使用hibernate...）。 3)、基于SpringJDBCTemplate的数据持久化方案(待开发)，可以使用spring的rowmapper封装一个小东西，其优点是小巧，灵活，可控。结合着jdbcTemplate就很好用了... 4)、基于Spring的声明式事物和编程式事物机制实现(已实现)，这个很爽，我们也是用它来实现事物管理与独立事物。 5)、基于AOP模型的日志审计组件(已实现)，夺标的时候用得着... 6)、基于AOP模型的业务异常组件(已实现)，这个不理解，是捕获了异常？异常这一块可以提供一套业务异常体系，通过配置的方式定义业务异常信息... 7)、“企业服务总线”实现。发布方式定下来之后基本就不会修改了...不是很明白其意义所在.. （3）、富浏览器端开发框架(eRedRIF) 可以提供一种界面配置的模式。通过xml来配置界面的显示。（好像楼主的已经支持了） 2)、UI主要依赖ExtJS，+ 部分自定义JSP标签。(已实现)，不晓得为啥子，一直对ext有点纠结，担心性能是一个方面，难道是因为它收钱？不过用它来做界面确实方便好看... 4)、基于FusionChartsFree封装动画图表功能。(已实现)，哈哈，这个做过demo，效果很不错的....至少拉近了与微软silverlight的距离。 5)、基于JXL的Excel导入和Excel导出功能(导出支持自定义模板标记语言哦,很方便的)(正在开发,即将杀青)，想问下这个如果导入的excel文件格式改变了，还能正常识别并导入吗？好像是有问题的，我还是倾向于使用txt的方式，并且实现配置输入规则（可空，最大长度，最小长度，类型，正则表达式等...）而且jxl导入导出大数据量时有性能问题。这块值得探讨呀.... 6)、可能还有一些Ext缺乏或不完善的UI组件会在后期继续封装成JspTag。你怎么解决的主子表问题？ext里好像是不支持主子表。 |
| 返回顶楼 | |
