我被要求將模塊添加到現有系統。在研究結構時，我發現了一些「怪異」的東西。該系統是基於struts1的。我是否在層層泄漏反模式？我該怎麼辦？
在一些jsp中，我發現有一些DAO調用返回實體對象。 在大多數JSP頁面中，都有一個<app:validate>標籤，它會打電話給DAO檢查訪問權限，如果不允許，將重定向到登錄頁面。 有一個accessDA對象，但它不僅僅是數據讀取，它還會執行一些訪問權限檢查。
我的問題是：
1） IMO是的，但：這不是一個漏抽象，這樣，正是因爲它是在一個標籤。存在標籤以從視圖中抽象實現細節。同樣有爭議的是，在動作中進行訪問查找使動作負責僅與視圖層相關的內容。
與封裝在標籤本身，如果有頁面上的標籤的許多用途有可能超過必要的數據訪問，減緩響應時間的數據訪問的另一個問題。一個聰明的標籤可以通過緩存值來緩解這個問題，或者可以在更深層次上實現緩存。
2）這樣的標籤應該對當前的用戶對象起作用，它應該已經封裝了用戶的權限（可能在登錄時）。也就是說，如果這些權利可能在用戶會話期間發生變化，則可能不足以使用緩存值來確定訪問權限。
3）我不知道;不知道更多細節IMO不可能回答。
4）取決於。多種方式做同樣的事情會導致維護噩夢。
如果有努力重新構造根據最佳實踐的應用，那麼是的，新的發展應遵循更好的模式。如果沒有，國際海事組織它更混亂的介紹做同一件事的多種方式，並使其更困難者誰遵循，因爲他們需要決定做什麼哪種方式，確定是否有之間的功能差異不同的方式等等。
在典型的MVC用法中，應該有一個明確的Separation of Concerns。含義，模型，視圖和控制器部分應該解耦。讓我來回答你的問題
1.呼叫DAO是導致一線泄漏
是。理想情況下，DAO調用應該在動作/處理程序類中。這樣獲得的數據放入請求/會話中，稍後由視圖渲染層拾取。
2.應用程序代碼實現，這是一個好的做法呢？（還是應該在行動CLA SS而不是在視圖做檢查。）
不應該有一個DAO每個訪問權限調用檢查。訪問權限應該作爲用戶登錄緩存，並且應該在後續請求中使用前述標記 進行檢查。所以在這裏，雖然不是直接違反，但不是一個好的做法。
3.是accessDA太胖嗎？
是的。看起來如此。
4.should我的新模塊遵循現有的結構？
在作出上述意見，我會建議反對。
呃，我不打算重新架構的應用程序，我更好地堅持原有格局。 – kunenkia 2012-01-17 08:18:22