忘掉普元EOS、构建自己的企业级快速应用开发平台

"逆向",服了,怎么生成? 基于Hibernate Model生成数据库表?
复杂化了,同学!!

另外在楼主的项目中又看到了我的表单验证框架的影子,

另外楼主可以看下我的项目,为代码生成器开发一套GUI,还是太麻烦了
http://code.google.com/p/rapid-framework

呵呵，badqiu，谢谢你的验证框架了，省了我不少功夫啊！另外看了你在google－code上的那些项目，很佩服你的创新精神，以后多多交流！

这种生成器太初级了，只能算工具级的

杭州信雅达的工作流接触过，感觉很一般。

不过，工作流发现国内的应用大家都比较关注签批，回退还有自由流这些Human Task的事情。

其实工作流的重点，应该是优化应用的架构，便于业务流程改造和系统整合吧。而这方面，需要遵循一些通用规范，一些大的厂商明显占有优势。

EOS最大的问题是将辅助开发给做的太过了，它试图用大大小小的构件来替代人工coding，但这世上不可能存在一套固定的构件就能去描述所有的业务场景，不然也就没有语言存在的价值了，在这点上，我个人觉得普元对自己产品角色的定位有问题，他应该去做的只是辅助开发，而不是试图完全替代和隔离代码
一句话，业务是活的，语言是活的，构件是死的（至少是半死不活）  ：）

反对

对于EOS的评论有些还是不能赞同的。

1，EOS限制了灵活性，这不应该是个需要拿出来说的问题，既然你用平台，就肯定不能指望向你编代码一样的随心所欲。这就好比传统意义上的裁缝和流水线上的缝纫工的区别，你得遵守流水线的规则，完成自己范围内的工作。

2，EOS很多Bug，呵呵，应该不是瞎说，但这也不是你否定他的地方，软件就是这样，做出来总有问题，但只要用心去做，Bug都是可以很快消灭的东西。

3，EOS有许多不足、性能也不行，都是问题，但都不是问题，只要是可以解决的问题就不是问题，给普元半年时间一切都能够解决。

我们看待一个产品的角度更多应该看他的设计思想和其发展的方向，这最重要，EOS如果能够真正带来效率，而价格也能平民化些，还是很有前景的，过程中的问题都是可以解决的，只要重视。

我们作为普元的竞争对手，其实还是比较欣赏普元的，不为他的产品，而是他的坚持。在这条路上能够忍住寂寞持之以恒是很不容易的。

不过普元在SOA上的夸张的宣传和大量的投入却让人感觉有些莫名其妙，SOA不是灵丹妙药，且和EOS关系也不大，不知普元为何如此投入，把精力投入到EOS上也许会更好些。

认同sunwine 对 “平台”的正确理解。
1）平台 的确是用来限制 开发者的
2）平台绝对会有bug(软件都会有bug）
3） 性能问题我不知道有多严重？ 能否告诉我个人？ 我们对性能是比较看重的，也花了很大气力。

我们对SOA的思想，主要还是在 EOS6.0和BPS平台 上融入的。
希望6.0发布后，您试用看看。