MVC實現中控制器servlet向jsptag轉變後參數維護方式的考慮

MVC模式提供了標准的表達層和業務層邏輯分離的模塊建立的原則，不過在JSP中實現MVC要面臨無狀態的環境，而狀態維護是MVC模式實現的前 題。因此，維護MVC中的狀態成?實現MVC/JSP時的最大難題和成本構成因素之一，它的缺點在struts項目中顯露無遺。狀態維護的困難最終表現? 多步控制參數維護上的困難，OPflow提供了一個試圖面對流程對象進行維護的方式，但隨著JSP標簽的出現，令JSP MVC中的C有可能更適宜用標簽實現，又進一步令整個JSP/MVC實現方式面臨又一次的檢討，但也可能是一次進步。

OPflow本質上是?了在WEB應用中實現MVC控制流而設計的。對于WEB應用中是否應該使用MVC模式，在技術社區中仍然存在很大的 爭議；而針對在網上兌現MVC模式的一些典型框架，象.net以及java的struts，在實際應用中都顯得不盡如人意，常常是得不償失。MVC在 WEB應用中的 Module問題上基本上達到了分層按功能劃分組件功能，V視圖部分以脫離業務和底層邏輯的方式顯視，這兩點都已經沒有太大的爭議；焦點在于C，如何定義 C？如何在沒有嚴格狀態保留的情況下安全地使用C控制器？在MVC模式中如果控制器每個操作，象每個servlet.action.do,都只是針對一個 目的對象（象一個訂貨記錄）的一個操作，那?也就失去了MVC的實際意義.把實際處理功能放在再下一級模件中實現倒也是一個妥協的辦法，不過，結竟那不是 正道，因?，這?討論的是是不可以使用MVC提供軟件開發和運行的效率。所以在實際操作中都是使用一些傳遞的參數，象"act"告訴控制器類型，通過變更 不同的參數從而進行不同的控制，以達到最大效率的代碼功能重用；這不一定是最大程度的功能組合，到底重用到什?程度合適，我覺得需要的實際的工作中按項目 要求進行微調。

同樣的邏輯也存在于V視圖上。如果開發者希望自已的視圖部分成?一個顯示框架(微軟的word,甚至是?覽器就是一個顯示框架)，而不是每一種顯示 對象的每一種細節都必須是一個程序的話，也必須是根據不同的指示參數提取不同的內容，以達到最大效率的和最低成本的模塊重用。這樣，無論是C還是V，如果 不想讓自已的開發變成隨機延伸的數不清的功能過分單一又過分相似的C和V，就將面對著另一個困難：處理一連串的act參數。而這些參數一般情況是放在 request.parameter中傳遞。在與一些版友的討論中發現一些朋友會混淆參數所存的命名空間，我認?，session一般用于會話跟蹤的參 數，而不應與界面關聯；而application應該是全系統的公共變量；同理，pageContext應該是僅止于當前頁面；如果不明確這個命名空間， 會把自已投入參數混亂的陷阱。

由于WEB應用不存在象VC++/VB/JavaSwing那樣的單一運行時狀態保持環境，所以當出現多步操作而必須共享部分變量空間時，大致只有 兩個辦法：一是在session中建立面向操作上下文（對象）的helper，二是在request過程中維持多步的狀態變量一致性。前者是較通用的辦 法，但缺點也是明顯的，就是每一種操作都要考慮一種helper,然後使用Vector,arrayList但集合類型地變量進行維護；顯然， struts中的 formBean和DynaFormBean,就是這樣一種helper。後者如果沒有一些工具幫助的話，在多步操作中要維持變量一致性簡直就是一場惡 夢。而Oplfow就是這樣一種工具。

hanva.Opflow的設想是使用一個外置的xml文件，把界面的操作形式看作是一種對象，定義?flow，每一步操作對應的URL看作是 flow的一個元素step，通過判斷所在的step，按約定方式組織各個環境的變量，包括變量的邏輯轉換，象垃圾回收站中deleted將取反之類。在 它的幫助下，可以把不同的頁面輕松組成一個個一步接一步自動維護的WEB功能模件。設想合理，實現後的運行也很理想，不過在運行一段時間後，仍發現有不足 之處。

其一，是xml的修改必須重?應用才能重新載入內存；其二，對于頁面人員來說，""這樣的路徑顯得不太直觀。第三；這不是OPFLOW直接的問題： 在面臨權限控制時，基于action的控制器不便實現與jsp同樣的界面控制邏輯。後面這一條可以作進一步的解釋。這是指在WEB上開放的連接，理論上是 說所有人都可以同步訪問的，無論它是V 還是C，只需要符合相應的條件，就可以實現操作。如果不能解決這個問題，那?WEB應用本身沒有可靠性可言，但如果解決方式過分複雜，象每一個程序進行一 次複雜的PMI驗證，然後最後兩句執行實際操作，這樣WEB的性能很差，而且整個項目開發的工作量會成級數的倍增。解決這個問題的關鍵在于共享單一變量空 間（會話helper是一種方式，不過缺點有如前述），並由一個共用的訪問驗證組件完成驗證。由于這樣的組件是複雜的，如果在一套系統上維持兩套達成同樣 功能但機制不一的PMI組件，那?程序開發和維護成本也會成倍數增加。

Jsp標簽提供了解決這個矛盾的一個途徑，並且，在此前的文章中已經提取，jsp標簽可以看作是一種在jsp中行的可運行時配置變量的 servlet，理論上可以由servlet實現的controler也可以由jsp標簽完成，並且，它較servlet可以訪問jsp上下文空間，從而 能夠實現與jsp訪問PMI控制同樣的邏輯。這是我決定把servletcontroller逐步轉向標簽controller的原因，盡管標簽仍沒有解 決jsp難以維護頂級模板的缺陷。不過，這就影響到MVC中關鍵的C的角度，並且，實際上是把V與C使用同樣的技術方式（標簽）作?統一媒介加以實現了， 從而也必然影響到 OPFLOW。這樣一來，我的構件JSPWEB應用的整個項目基礎模式就出現了變化，雖然很可能是進步，但模式的成熟總是需要一些波節，它的優點和缺點也 必須在使用過程中才能真正體驗出來。

原來以?JSP控制器標簽的使用會大大降低opflow的必要性，因?opflow的其中的一個目的是彌補servlet不能方便地調節運行參數而 開發的;而調用控制器標簽的jsp頁面本身也可以作?參數調節的空間，這樣opflow的必要性是不是就減低了？但實際使用時卻發現對于運行時過程參數的 維護，opflow還是很有必要的，除非在標簽中集成原來的維護參數的底層代碼，這是可能的，因?隨著標簽的使用，jsp數量的增加已經不意味著太大的維 護量，它們實際上只是一兩個標簽的載體。至于如何合在一起使用才最高效，還需要在應用中慢慢總結，歸納出一套可靠高效的程序模式才算對得起自已此前的工 作。

從當前的情況看，操作標簽是對servlet控制器的更替而不是對opflow的更替，標簽本身不能簡單地實現低成本的參數維護；不過，在單一步驟 時，這是無意中發現的，由于ActionTag是使用了與Struts.ActionServelt同樣的轉向代碼，我並且加進了從若?空就從 header中取 referer的部分作?轉向目標；這樣一來，無意中就令單步操作在操作完畢後反回了同條件參數的顯示頁面——顯然，把標簽直接寫在這些頁面上也可以達到 同樣的效果。不過需要在標簽生效前先用logic.prisent之類的判斷一下是不是要先進行標簽標定的業務操作。

http://blog.csdn.net/zwwwxy/archive/2005/04/13/345658.aspx

http://zwwwxy.blogchina.com/1185354.html
http://javaxml.blog-city.com/mvcservletjsptag.htm