承接上篇的簡單介紹,下面詳細介紹整個架構的大致結構。
先來看一下整個架構套件的結構:
可以看出架構套件含的包很少,包的結構也超簡單。這裡 涉及Filter、ActionSupport、Router等三個概念,他們之間的關係,通過來表示:
圖也不規範,說不上來是哪個UML圖,不過通過它也能看出一個請求到達時,架構基本的處理流程。首先由Filter攔截到所有請求,然後把請求交給所有註冊的Router類,如果請求的Url正好是一個Router要攔截的,則把此請求交給這個Router,架構不再把請求向下傳遞。Router得到請求後,分析Url,通過Url裡的資訊把請求交給對應的ActionSupport的子類來處理。
這裡攔截採用Filter來處理,這跟多數的web架構一樣,使用Filter比Servlet有更多的能力進行請求的分發。首先在一個web工程的web.xml檔案中組態架構的UrlFilter類來攔截所有的請求。需要注意的一點是dispatcher 要設定為request,如果設定了forward的話,由架構內部進行的forward又會被架構攔截,從而造成無限的迴圈。Url-pattern設定為/*,表示所有的請求都會攔截,從而把對url分發的權利交由架構本身,而不是採用jsp規範裡的url分發策略。架構在處理所有請求的url 時,依次交給各個Router類來處理,如果Router類判斷是符合自己的url格式,則分發給 action 處理。如果不能處理再交給下一級的Router,最後url經由所有Router處理完,剩下的資源檔的url,如http://xxx.xxx.xxx.jpg,則架構調用filter的doChain()方法,通過filter的過濾去訪問web裡的資源。
<filter> <filter-name>unicornWeb</filter-name> <filter-class>com.mh.mvc.filter.UrlFilter</filter-class> </filter> <filter-mapping> <filter-name>unicornWeb</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> |
大致的原理就是這樣,在下篇介紹架構的詳細實現。