推荐：
1.老庄的"敲响OO时代的丧钟-面向对象已死"系列
http://zbw25.spaces.live.com/blog/cns!BD4EFBFAF436336C!220.entry?_c=BlogPart
2."丧钟为谁而鸣"系列
http://www.blogjava.net/raimundox/archive/2005/12/20/24851.html
3.javaeye中的相关讨论

用layoutData.exclude属性可以重新布局。
例如：想不显示button1，

button1.setVisible(false);
GridData layoutData = (GridData)button1.getLayoutData();
layoutData.exclude=true;
button1.getParent().layout();

1.bom的变动不是通过ECN（工程变更）来维护的吗？
2.pdm和erp的bom差异应该通过技转部门来控制，好像业务流程不完全。
3.在oracle中可以使用SYS_CONNECT_BY_PATH构造路径，效率还可以，我在构造产品结构树时就是用这个函数实现的。
eg：（摘自oracle文档SYS_CONNECT_BY_PATH）
SELECT LPAD(' ', 2*level-1)||SYS_CONNECT_BY_PATH(last_name, '/') "Path"
FROM employees
START WITH last_name = 'Kochhar'
CONNECT BY PRIOR employee_id = manager_id;

有人说在失败中更能学到经验，对这句话我很犹豫。
我曾经历一个项目，最开始预计是半年完成（14个开发人员，其中项目经理1人，开发经理1人，系统分析员4个，其他大多是高级程序员，可谓是公司的重量级组合，豪华阵容），后来历时3年半才勉强结案。坚持到最后的人算辈分，有的说经历了四代人，有的人说经历了五代人。我自认为应该是第三代中的一员，在项目中熬了1年，混不下去了，觉得对项目的余热都已经发挥完了，最终含恨离开。说起在项目中学到的东西，可能最大的经验就是能忍耐。在得不到公司领导、客户、以及任何人的信任的时候还努力为项目做一点点贡献，没有奖金，没有加班费。至于其他，则是仁者见仁，智者见智了。
所以如果注定要失败，我觉得还是早点退出比较好，毕竟人的黄金时代没有几年，经历成功比经历失败好多了。大老板有钱烧，但是我们却浪费不起青春。
附注：因为这个项目导致一个项目总监，2个部门经理离职。在这个项目中写过代码的人数达...(算了，太难统计了)。昨天他们系统上线，祝各位兄弟们一路走好！

源码已经下载到。谢谢！

1.EasyDBO的源代码无法下载，请问有人能down下来了吗？
2.能具体说说EasyJF各个项目的优势和适用的目标场景吗？因为如果想取得成功，必须在某一特定领域成为第一名。EasyJF的领域是什么呢？

我对EasyDBO很感兴趣，因为我的实体层要分布运行，用Hibernate和其他各种工具都有缺陷。

一个超轻量级的ORM还是很有意义的。

请问能介绍EasyDBO和Hibernate相比有什么优缺点吗？

只一次生成的情况可以使用wizard。

反复生成的情况可以把手写的类和生成的类分离，手写的类继承自动生成的类。
compiere中就这样做的，例如
public class MInventory extends X_M_Inventory implements DocAction{

MInventory 是手工维护的类，X_M_Inventory 是自动生成的类。
所有X_可以重复生成。当然，可能X_M_Inventory 会影响MInventory，但这种影响造成的修改是必然的，并且还影响单元测试。

Code Generation In Action. pdf中有比较系统的描述
包括生成dbschema ， dao，业务逻辑，service，UI，test以及代码生成的各种技术、技能。

以下愚见，请随便看看。
--------------------------------------------
那要看你是什么角色了

如果你是老板，错了，你应该不是老板，下一个

如果你不是项目经理，
如果 你的银行账户上的钱还够用，则 做最后的努力去和大老板交流过程管理，如果失败就考虑另谋高就。成功则需要某种形式的任命。
如果 你的银行账户上的钱不够用，则 左右逢源，见风使舵。养家糊口要紧呀，在江湖上混，难免要夹着尾巴做人的。

以下假设你是项目经理，也就是项目的负责人，你就没办法逃，也没办法混了。
首先要把手下几个搞定，手下搞不定，这时就难办了，假如项目成员中还有技术总监的小舅子，那你肯定完了。然后对技术总监和大老板阳奉阴违，他们对于文档的要求可以用时间作为托词，或者花很少的时间找些资料填入。

对于那位喜欢画UML的，可以允许他在完成本职工作的前提下画，甚至可以每天抽出10到15分钟看看他画的东西，然后适当表扬。毕竟这样的个人爱好总比喜欢打游戏或者聊天泡妞健康。这些东西从项目的角度可能没什么用，但是可以用来应付技术总监。

尽可能的偷工减料，首先把测试用例减少，只对比较复杂和重要的部分作单元测试。然后尽可能把界面先开发，容易实现的先开发，业务逻辑先空着，这样有利于业务人员去糊弄对方的具体办事人员，有利于收款（否则收不到款，会影响各方面的情绪，导致矛盾激化）。

然后保持强悍的心灵和认真负责的态度来开发程序，等待项目延期。
如果一年内你被炒掉，恭喜你，你在职场上的经验还不够，需要再学习几年。
如果人员流动率>=75%,结果很难预测。
如果一年内你没有被炒掉的并且人员流动率<=75%的话，项目应该会顺利结案。
我看好你哟！

难以想象NC现在居然还是在这样的技术规范下维护
以上所列有很多项已经过时（例如第4条关于case when，oracle从9已经支持了），并且直接这样使用sql开发的方式已经值得推敲。
可能直接使用朴素的技术也能开发出很好的产品，让我想起了compiere，唉，技术界可能太浮躁了。
不管怎样，还是很高兴能看到这样一个重量级的产品的技术资料。谢谢了！

不错！
有更多的细节吗？
比如说表的命名规则，界面规范，如何跨数据库，使用了哪些外部包

令号可能指工单，又称工令单，制令，work order
排产可能指排程，schedule

开始尽量采用简单的架构和过程，创业之初很缺钱，架构和过程都是很耗钱（或者时间）的。
找一种简单可行的方式开始运作，然后把注意力放在业务上，毕竟是在经营一个公司，而不是开研究所。
仅供参考。