不管什么框架，入门至少半年，别说精通呢！

现今流行快速建模，快速开发！

OO语言越简单越好，oo语言本身就是直接面身客户。想了解底层的复杂，学汇编、C就好了。

浪费我时间的东东，通通是垃圾！！！！！！！！

打死活到100岁，笑死

中国的程序员要做的事情太多了~~~
程序员（统称）没有合理的分工
很多时候，我们并不明确，
那到底是不是该我来做的事情？
看看现在的程序员，
什么都要学，什么都要做
（多学点知识，总有用的吧。
但不能什么事都要程序员来做）
能不复杂么？
是不是该考虑下，
如何分配管理细化精炼程序员呢？

我的经验是不断总结可以复用的技术，例如我们觉得获取数据库连接比较麻烦，那么可以封装一个固定的类来获取数据库连接，为了提高性能，那我可以让这个获取的连接从连接池里面获取而不是直接创建，这个时候工作就变成了两个部分，一个是前台使用获取数据库连接的类的程序，这些程序无需改进，第二部分就是将链接的直接获取改为从池中获取，这是属于后台工具类的修改工作。
对于开发来说也许作为一个针对数据库的WEB应用项目，大多数程序都在如何对数据库的数据增删改上面，我们要考虑的应该是如何压缩这部分的工作，而把其中通用的和具体的数据库、表无关的东西总结出来，因此你的简单还需要稍微再复杂一层，至少要把里面的那些和你具体的业务有关的东西要剥离出来。

还有一点需要指出的就是说到底数据库是面向关系的，可以思考一下关系和对象还是有很大区别的，数据库如果要面向对象来设计自然无法满足范式的要求，而导致大量的冗余数据，如果硬要把每个表都变成bean
也不一定是好的思路，因此任何框架我想应该在解决对象和关系的矛盾上面。

对于程序的维护来说也不是说只修改XML就简单，编译也不是什么难事，关键还是在于采用统一的开发模式和框架，包括一层层对技术的抽象，难的东西被逐步排除到业务之外，集中形成了框架或者API，而他们的稳定性可以由高端的技术人员来更新和维护，对前台保持良好的有效的接口，一方面保持了稳定性和高可用性，另一方面也使得每次技术的革新不会影响已经开发的业务程序。对于普通技术人员只要能够理解相对简单的程序和配置，就可以进行调试和修改就可以了，无论是改你的java程序还是XML文件，都没有难易高低之分。

不同意楼上所说的面向对象设计就会导致冗余，面向对象设计恰好是消除了冗余，我在另一篇帖子里（http://www.jdon.com/jivejdon/thread/34663.html）也提到关于第三范式和冗余，有兴趣不妨共同讨论一下。

看把你急的，一下就冒出了这么多名词。这些名词我都懂，但我不以为然。看来在一个“以复杂性为生”的人云亦云的行道里，连回复的贴子也是这么复杂，好象只有“复杂”才能体现项目价值，才能糊弄客户以赚取更多的利润，所以容不得一点“简化”的声音的。说那么多有什么用，只说当一个数据表增加两个字段后，你的增删改功能要改几个文件，几行代码。
**********************
lz 的这个问题 谁给说说？

大家要明白很多情况下SRC文件下载修改必须在本地完成,然后把编译好的CLASS文件传递到远程覆盖原来的文件,覆盖过程中可能会导致一些失误,因为在远程没有编辑器帮你去分析代码到底哪里有运行错误,可能因为你一个不小心就把类的名字改错了 ,而察看CLASS文件很不方便,所以粘贴CLASS文件的方式有一些不确定因素,而且也有点危险.XML可以在不粘贴CLASS文件的同时改变类的指向和引用,可以改变一些业务的运行方式,最小限度来说可以直接更改数据库联接操作,同时方便快捷,而且如果一旦改错了还可以直接按CTRL+Z还原回来，其实也挺方便的 赫赫

现在的框架XML多到都可以算作源代码的一部分了，修改起来一点也不简单，而且没有编译器检查错误。

退一步讲，就算XML改起来很容易，派个技术一般的去改一下就可以。问题是，企业应用中，真正改代码的时间占的很少，更多的时间花在测试和批准修改上。

顺便问一下，对于一个已经存在的系统，如何ORM？难道要重构数据库结构？