載自：
即使對於一個大部分基本邏輯都包裝在標簽/類/servlet/EJB中的網站，以至於在jsp(SUN企業級應用的首選)中看不到任何的javalet代碼，隨著規模的擴大和項目時間的延長，目錄中總是堆滿了越來越多的垃圾文件。有些文件本身不是垃圾，而是被包容的子文件，但是jsp(SUN企業級應用的首選)服務器可不管這個，如果不是jsp(SUN企業級應用的首選)後綴，它就會被jsp(SUN企業級應用的首選)把源代碼下載到客戶端；或者，同樣是jsp(SUN企業級應用的首選)一樣時就讓維護者頭大。如果不是采用良好的文件策略，那麼隨著規模的擴大，一般的中大型站點堆出幾千上萬的jsp(SUN企業級應用的首選)文件，其中每一個模塊分上幾十個，是非常正常的；這時侯，管理這些文件就成為一件艱苦的工作；事實上，如果不是多人分管的話，一個發布管理員真正能夠維護的文件如果超出一百個，效率就會急劇降低。何況，還有更重要的sql文件，class文件，xml(標准化越來越近了)設置文件……。為什麼總是努力使用bean/fragments/標簽/ORclass（如EJB），這就是原因之一。事實上，從事過大型項目的開發員對於後期目錄中那種不知那個有用那個無用但卻要麼不管要麼只能一個個識別的經歷，總是一種難言的痛苦。經歷過這種痛苦也會對可重用組件在項目中實際上降低了後期維護費用的感受良深。
要實現高度的重用性，減少需要維護的文件的數量，就需要對系統架構甚至前台框架都進行抽象，重用的方式除了Class等方式外，還可以使用shellscript幫助，特別是對那種必須分割出目錄管理而實際上結構非常相似的類型。通過這個辦法，即使是很大的項目，也可以把需要維護的jsp(SUN企業級應用的首選)文件，不含java類庫壓縮到一百個以下，包括用於包含的小jsp(SUN企業級應用的首選)片片fragments。
良好的命名規則可以進一步提高對文件的識別，也便於使用shellscript按文件類型進行管理。為了防止被jsp(SUN企業級應用的首選)服務器下載到客戶端，如果是與apache(Unix平台最流行的WEB服務器平台)結合的話，可以在apache(Unix平台最流行的WEB服務器平台)中建立禁止下載的文件類型。我一般是把這種文件命名為jsp(SUN企業級應用的首選)_，為了達到這種命名的規范性，甚至不惜把已經寫好的程序改一遍，幸好，在良好的組織框架下，文件總是只有幾十個，並且只需要改一兩行的幾個字母。盡管如此，每次都仍是讓我感到生畏，這種規范工作的確是最不令人興奮的。
建立良好的命名規則和目錄結構，也是為了可以有效重用已有工作的前提，但什麼時侯應該達到重用呢？畢竟即使是很相似的框架類型，在面向重用要求時，就意味著很多的if-else。logic:equal/present之類，在Class中可以通過接口和繼承實現代碼的高效率，而在jsp(SUN企業級應用的首選)中，如果重用變型達到三個以上，大量的if-else之類就令混帳代碼冗余廣泛伸延，而在jsp(SUN企業級應用的首選)文件內部令維護難道大大增加一個檔次；或者一個簡單的要求就需要include十次八次，同樣是加大了維護成本。（要知道，接手者，甚至是自已吧，過了幾個月，對於開發中的印象早就消失干淨了。）
這是一個難以協調的問題，可以調整的空間很小：如果不重用而一個文件任務專用，意味著每次需求變動時要重復維護多個非常相近的文件；超過三個的話，也就等於說這個文件建立方式是低效的。而如果文件復用的話，依靠在jsp(SUN企業級應用的首選)中的判斷實現，那麼文件變得難以維護調試的界限也是三個左右。希望把這種代碼包含進Bean是愚蠢的選擇，Bean不是做這些事情的，原則上，非表達層只應該包含業務邏輯，不應帶有任何專用的表達層代碼，象html。
問題的焦點在於，jsp(SUN企業級應用的首選)作為表達層的實現方式，本身缺乏對象抽象的能力，只能依靠在jsp(SUN企業級應用的首選)中的邏輯判斷適應條件變化；而理想的MVC，view視圖需要的是一個定義視圖表達形式的對象，jsp(SUN企業級應用的首選)根據這個對象的設置生成框架需要的html代碼，甚至生成jsp(SUN企業級應用的首選)本身。因此，實際上對於這種大型的站點來說，在數據庫以及數據映射和業務邏輯的中間層以上，表達層以下，需要的是一個jsp(SUN企業級應用的首選)的發布系統。這個發布系統根據用戶自已定義和開發的框架抽象，生成jsp(SUN企業級應用的首選)目錄/文件等。它到底應該如何運行，我還沒有明確的解決方案，不過這個系統會有用的。
