推薦：
1.老莊的"敲響OO時代的喪鐘-面向對象已死"系列
http://zbw25.spaces.live.com/blog/cns!BD4EFBFAF436336C!220.entry?_c=BlogPart
2."喪鐘為誰而鳴"系列
http://www.tkk7.com/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

開始盡量采用簡單的架構和過程，創業之初很缺錢，架構和過程都是很耗錢（或者時間）的。
找一種簡單可行的方式開始運作，然后把注意力放在業務上，畢竟是在經營一個公司，而不是開研究所。
僅供參考。