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

看到几乎所有的人的角手架都是基于数据库生成的

搞一个简单的配置不好么

可以生成对应数据库的DDL
不用担心数据库兼容性的问题
POJO里再也看不到全是大写的命名

用eos最大的感觉就像被戴上了枷锁一样，用代很容易实现的问题需要用一大堆的图形化组件来实现，难道这是进步吗？

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

最可笑的是你拼一个带规则的字符串也要用构件来做

见过用流程图表现一个拼字符串的过程么?  eos:我能

如果你不想这样干，就得自己做一个构件：定义一个static类！

EOS在产品的最初规划上是有些问题的，粒度太小了，所以一个简单的东西都要画个图。这是个较大的问题。

但如果EOS定位在辅助开发上，那就是个IDE啦，这不是他的定位，我们无法否认业务的复杂性，但也并不意味着死的构件的就无法实现复杂业务，编程语言其实也是死的，只是他粒度小，层次低，所以可以构造出大量复杂业务。构件其实也一样，如果把握好粒度，和考虑复用灵活性，构件同样也能实现复杂业务逻辑。

EOS在粒度上是有问题的，但并不意味着构件复用快速开发不行，我们的产品和多年的切身体验其实一直在证明这种想法的可行性。

http://www.extract.com.cn:8855 这是一套完全通过组件复用开发实现的系统，没有Java代码，也没有JSP页面，完全配置开发。

构件、组件复用快速开发的可行性和灵活性其实并无大的问题，关键点是如何获得高质量的可复用组件，并提供一套稳定可靠的复用方式。

疏不知配置写多了比代码更难维护.而妄图用构件的方式来全部解决应用开发的复杂性，那就不用程序员了.
而对于配置文件，现在提倡的是零配置，所以现在类似rails的框架大行其道.

哈哈. 看到了这些, 感觉还是EasyJF团队的思想有点前沿. 上面讨论的功能,他们通过easyjweb+spring+JPA完全实现了. 什么零配置啊. velocity啊.  逆向生产表啊.  他们里面都有了.

一套完整的平台不仅仅只是用来提高实体的增删改查的开发效率，还需要对门户定制、流程性的配置应用、报表、日志监控、缓存、消息方面都要有完备的支持和综合考量的。

用了eos以后我暂时得出两个结论：
    1.千万不要使用那些太花哨，看起来很傻瓜化的ide，那些东西十有八九是一个漂亮的陷阱，能给提供一些好用的类库足矣。
    2.傻瓜化的ide带给你的好处与它带给你的bug几乎一样多。
    3.对你的项目的开发进度起决定作用的是明确的需求和好的设计，而ide所起的作用与他们相比要小的多。

总结：花很高的价钱去买一个你所不了解的平台简直是自己给自己找麻烦

badqiu 应该理解错我所说配置的意思啦，如果手工去配置XML文件达到开发目的，这显然是愚蠢的。badqiu 其实可以看看我们的产品，有兴趣可以研究下，我们提供试用版本下载。

xingqiliudehuanghun 这个结论下得感觉有些早，EOS可能给你带来过痛苦，但建议不把这种感受扩大为广泛结论。