發布日期： 4/1/2004
| 更新日期： 4/1/2004
front controller（前端控制器）
版本： 1.0.1
本頁內容
上下文問題
影響因素
解決方案
示例結果上下文
測試考慮事項
相關模式
致謝您已經決定使用model-view-controller
(mvc) 模式將動態 web 應用程式的使用者介面邏輯與業務邏輯分隔開來。您已經考察了page controller
模式，但您的頁面控制器類具有複雜的邏輯，並且是較深的繼承層次結構的一部分，或者，您的應用程式是基於可配置的規則來動態確定頁面導航的。
返回頁首
如何為非常複雜的 web 應用程式構建最佳的控制器結構，以便在避免**重複的同時實現重用性和靈活性？
返回頁首
下面是適用於front controller 模式的、由 model-view-controller 帶來的各種具體的影響因素：
•如果在系統的不同檢視內複製公共邏輯，則需要集中此邏輯才能減少**重複量。刪除重複的**是改進系統的總體可維護性的關鍵。
•資料檢索最好也集中在乙個位置進行處理。乙個好的示例是，讓一系列檢視使用資料庫中的相同資料。與讓每個檢視檢索資料並重複資料庫訪問**相比，在乙個位置實現對此資料的檢索是更好的做法。
•如 mvc 中所述，測試使用者介面**往往是耗時而乏味的。通過區分單各自的角色，可以提高總體可測試性。這不僅適用於模型**（在 mvc 中已說明），而且適用於控制器**。
以下影響因素可能使您決定使用front controller，而不是page controller。
•page controller 的一般實現方法涉及為各個頁面所共享的行為建立乙個基類。但是，隨著時間的推移，由於要增加非所有頁面公用的**，這些基類就會不斷增大。若需要定期重構此基類以確保其只包括公共行為，則需要制定規則。例如，您不希望由頁面檢查請求並決定（基於請求引數）是否將控制權轉移給另乙個頁面，因為這種型別的決定對於特定功能來說更具體，而不是所有頁面共有的。
•為了避免在基類中新增過多的條件邏輯，您會建立更深的繼承層次結構以刪除條件邏輯。例如，在具有三個功能區域的應用程式中，只使用乙個包含應用程式公共功能的基類可能是很有用的。每個功能區域可能還有另乙個類，該類繼承總體應用程式的基類。乍一看，這種型別的結構是簡單的，但它通常會導致非常脆弱的設計和實現，並給**帶來問題。
•page controller 解決方案描述了每個邏輯頁面使用乙個物件。當需要跨多個頁面對處理過程進行控制或協調時，此解決方案將不可行。例如，假定在 web 應用程式中具有複雜的可配置導航（以 xml 格式儲存）。當收到請求時，應用程式必須根據其當前狀態查詢下一步要前進到哪個位置。
•由於page controller 是通過每個邏輯頁面使用乙個物件來實現的，因此，很難在 web 應用程式的所有頁面中一致地應用特定操作。例如，安全性最好以協調方式實現。讓每個檢視或頁面控制器物件分別處理安全性是有問題的，因為它可以被不一致地應用，並導致安全問題。此問題的其他解決方案還將在intercepting filter
中進行討論。
•返回頁首
front controller 通過讓單個控制器負責傳輸所有請求，從而解決了在 page controller 中存在的分散化問題。控制器本身通常分為以下兩部分實現：處理程式和命令層次結構（見圖 1）。
返回頁首
請參閱在 asp.*** 中使用 httphandler 實現 front controller。
返回頁首
front controller 模式具有下列優缺點：
優點 •
集中化控制。front controller 用於協調向 web 應用程式發出的所有請求。此解決方案描述了使用單一控制器，而不是page controller 中所用的分布式模型。此單一控制器處於很好的位置來實施全應用程式範圍的策略，如安全性和使用情況跟蹤。
•執行緒安全。由於每個請求都涉及建立新的命令物件，因此命令物件本身不需要是執行緒安全的。這意味著，命令類中避免了執行緒安全問題。但是，這並不意味著您可以完全避免執行緒問題，因為命令所作用的**（即模型**）仍然必須是執行緒安全的 [fowler03]。
•可配置性。只需要在 web 伺服器中配置乙個前端控制器；處理程式執行其餘的排程。這簡化了 web 伺服器的配置。一些 web 伺服器是很難配置的。使用動態命令可以新增新的命令，而無需進行任何更改 [fowler03]。
缺點 •
效能考慮事項。front controller 是用來處理對 web 應用程式的所有請求的單個控制器。在這兩部分中，應該仔細檢查處理程式中是否有效能問題，因為處理程式將確定負責執行請求的命令的型別。如果處理程式必須執行資料庫查詢或 xml 文件查詢才能作出決定，則可能導致效能非常緩慢。
•增加了複雜性。front controller 比page controller 更複雜。它通常涉及將內建控制器替換為自定義的 front controller。實現此解決方案會增加維護成本和新手的學習難度。
返回頁首
返回頁首 •
intercepting filter
。此模式描述了在 web 應用程式內實現重複功能的另一種方式。intercepting filter 的工作原理是，先通過可配置的篩選器鏈傳遞每個請求，然後將控制權傳遞給控制器。篩選器往往會處理較低階別的功能（如解碼、授權、驗證和會話管理），而 front controller 和 page controller 則處理應用程式級別的功能。篩選器的另乙個方面是它們通常是無狀態的。例如，在開始對使用者授權時，web 伺服器必須驗證會話。如果使用者已通過身份驗證，則過程繼續進行。如果沒有，則將使用者重定向到其他位置。intercepting filter 的乙個優點是，在大多數實現中，不必修改頁面本身就能新增其他功能。
•page controller
。此模式是 front controller 的更簡單替代方案。在 page controller 模式中，每個頁面各有乙個控制器物件，這與所有請求使用乙個物件的方案相反。對於大多數應用程式來說，page controller 是更合適的起點。僅當需要front controller 時才應該使用它。
前端控制器模式
前端控制器模式 front controller pattern 是用來提供乙個集中的請求處理機制，所有的請求都將由乙個單一的處理程式處理。該處理程式可以做認證 授權 記錄日誌，或者跟蹤請求，然後把請求傳給相應的處理程式。以下是這種設計模式的實體。我們將建立 frontcontroller disp...
前端控制器模式
前端控制器模式 front controller pattern 是用來提供乙個集中的請求處理機制，所有的請求都將由乙個單一的處理程式處理。該處理程式可以做認證 授權 記錄日誌，或者跟蹤請求，然後把請求傳給相應的處理程式。以下是這種設計模式的實體。我們將建立 frontcontroller disp...
SPA前端許可權控制方案
這裡我們需要用到 vue 前端mvvm框架 vuex 狀態管理機 vue router 路由 axios http請求庫。1 登陸事件login 1.觸發登陸事件 dispatch login actions commit types.login success,res.data.data 2 獲取...