Shao Fan

          關于JAVA與軟件工程
          posts - 31, comments - 71, trackbacks - 0, articles - 4
            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

          2007年4月6日

          目前開發人員對系統開發的一個共識是使用三層架構,分為表示層,業務層,和持久層。而這三層之間的依賴關系如何?比較常見的一種看法是

          表示層 --> 業務層 --> 持久層

          這表明了層與層之間的調用關系,表示層通過調用業務層來完成任務,而業務層則調用持久層。從另一個角度來看,一種依賴關系是

          表示層 --> 領域模型(Domain Model) <-- 持久層

          表示層和持久層都應該理解(recognize)領域模型。而領域模型則是業務層的一部分。業務層正是系統的價值所在。雖說表示和持久也很重要,在某些系統中可以說是很關鍵,但是它們的最終目的都是為業務服務,所以業務層應該是系統的核心

          基于以上的認識,在系統設計的時應首先分析需求得到領域模型,找出系統中的實體、對象(靜態的一面),并明確大致的業務流程(動態的一面)。 而另兩層應盡最大努力為業務層服務,且盡量減少業務層受另兩層的限制。


          各層的職責:

          表示層:負責顯示信息,及從系統外部得到輸入。表示層的設計決定系統界面的可用性,及信息輸入和展示的可靠性。表示層只知道如何展示信息,及收集用戶輸入,并不知道該如何對這些輸入進行處理來完成業務。

          業務層:完成業務邏輯。業務層設計決定客戶價值是否能夠得到實現。這是系統的關鍵。外在的表現是功能性。業務層設計和實現的失誤表現在用戶端即功能缺失,功能不可靠等。如果需要對業務層的業務規則進行解耦,則可以使用規則引擎如Drools,把業務規則分離出來。但分離后的業務規則仍屬于業務層。業務層知道如何對用戶輸入進行處理,能夠應用業務規則完成用戶所需的業務,但它不知道數據如何讀取和保存。

          持久層:負責用戶信息的持久化。持久層的失誤表現在外即數據處理(儲存,展示等)不可靠。持久層完全不知道業務,只專注于數據存儲和讀取。所謂持久化并不一定是指數據庫,任何方式的持久化(通過文件,網絡的持久化等)都應由持久層完成。

          各層的設計都會直接影響系統性能。

          三層的體積大小和復雜度在不同的系統中可能會有很大的不同。比如說GOOGLE的搜索引擎,它的界面很簡單,可以想像表示層是比較容易實現的,而它的業務層,關系到處理關鍵字,分析搜索結果,決定排名等,而持久層則要負責處理超大量的數據。業務層和持久層則相當復雜。而有的系統持久層會很小,比如殺毒軟件,媒體播放軟件等。業務層小而另兩層大的例子暫時還沒有想到:)


          posted @ 2007-09-08 19:45 shaofan 閱讀(5133) | 評論 (2)編輯 收藏

          help是一個內置函數,所謂內置函數,就是在Python中被自動加載的函數,任何時候都可以用。參數分兩種:

          • 如果傳一個字符串做參數的話,它會自動搜索以這個字符串命名的模塊,方法,等。
          • 如果傳入的是一個對象,就會顯示這個對象的類型的幫助。

          比如輸入help(’print’),它就會尋找以’print’為名的模塊,類,等,找不到就會看到提示信息。而print在python里是一個保留字,和pass,return同等,而非對象,所以help(print)也會出錯((kkkkkkk))。

          舉個例子:

          1 help(’sys’) #會列出sys模塊的幫助
          2 = [1,2,3]
          3 help(a) #會顯示list的幫助
          4 help(a.append) #會顯示list的append方法的幫助

          python安裝自帶的library reference,2.1節是關于內置函數的。

          Reference Manual的6.6節可以找到關于print的東東。

          posted @ 2007-06-05 06:28 shaofan 閱讀(2770) | 評論 (0)編輯 收藏

          Struts2默認theme是xhtml,它用表格來對表單中的控件進行排版。它也提供一個客戶端的js驗證功能,但是它的js腳本卻有些問題,在某些情況下,前次驗證的提示信息無法被清除,提示信息會不斷的累積顯示在屏幕上。而按照設計,每次提交表單時應只顯示每次驗證的出錯信息。

          它的客戶端驗證的流程大概是這樣,用戶提交表單時,對各個控件的輸入按預先設置的規則進行驗證,如果有問題,則清除表單里原有的出錯提示信息,并寫入新的提示。其設計的功能是把出錯信息寫表格里出錯控件的上方,以便用戶看得更加清楚。問題就出在其用來清除原出錯信息的函數,其代碼是這樣的(在struts.jar的template/xhtml目錄下可以找到):

           1 function clearErrorMessages(form) {
           2 
           3     var table = form.childNodes[1];
           4     iftypeof table == "undefined" ) {
           5         table = form.childNodes[0];
           6     }
           7 
           8     // clear out any rows with an "errorFor" attribute
           9     var rows = table.rows;
          10     var rowsToDelete = new Array();
          11     if (rows == null){
          12         return;
          13     }
          14 
          15     for(var i = 0; i < rows.length; i++) {
          16         var r = rows[i];
          17         if (r.getAttribute("errorFor")) {
          18             rowsToDelete.push(r);
          19         }
          20     }
          21 
          22     // now delete the rows
          23     for (var i = 0; i < rowsToDelete.length; i++) {
          24         var r = rowsToDelete[i];
          25         table.deleteRow(r.rowIndex);
          26         //table.removeChild(rowsToDelete[i]);
          27     }
          28 }


          看這個函數的前三行,它試圖取得form的第1個或第2個子節點,并把它作為table來處理(看接下來的幾行)。要想清除表格里的錯誤信息,首先要取得表格本身,這沒錯,但是如果第1個或第2個子節點不是table的話,腳本就會出錯,造成原出錯信息無法清除,這樣每次提交后的提示信息就會累積在屏幕上。

          要解決這個問題有兩個辦法:
          • 寫代碼時要小心,保證form的第1或2個子節點是table,不要在生成table前加其他代碼。
          • 或,修改xhtml的validation.js,使它總能獲得正確的table元素,重新打包到struts.jar。
          剛看了一下Struts的JIRA,已經有人報告了這個問題(id WW-1802),而且這個bug在2.1版本中已經解決了。

          posted @ 2007-06-03 17:56 shaofan 閱讀(2542) | 評論 (3)編輯 收藏

          假設:用兩者寫一個最小的WEB程序。
          過程可以參照:
          1.struts的就太多了,隨便哪個都可以
          2.python/django可以看limodou寫的Django step by step

           

          Java/Struts/JSP  Python/Django
          開發步驟 1.在web.xml里配置struts的servlet
          2.在struts-config.xml里配置URL和action的映射
          3.寫action
          4.寫JSP
          1.在urls.py里配置URL到方法的映射
          2.寫相應的方法
          3.寫HTML模板
          調用過程 1.根據web.xml的映射調用struts的servlet controller
          2.servlet controller根據struts-config.xml的映射調用相應的action
          3.action處理請求
          4.JSP渲染顯示
          1.根據urls.py的映射調用相應的方法
          2.方法處理請求
          3.HTML渲染顯示


          相比之下前者用了兩層才把一個HTTP請求映射到實際處理的方法:第一次是servlet的映射,第二次是struts action的映射。
          而django則一次就從URL映射到相應的方法了。

          另外一個比較顯著的區別,也是基于java和python的語言上的區別吧,java的所有方法必需包含在一個類中,因此action mapping配置時是映射到類,而action在實現類則應實現事先約定的方法(通過繼承或實現接口)。而django則直接得多,可以直接在配置里寫明處理請求的方法名。


          posted @ 2007-04-06 19:11 shaofan 閱讀(4978) | 評論 (0)編輯 收藏

          主站蜘蛛池模板: 聂荣县| 镇坪县| 白朗县| 班玛县| 五常市| 花莲县| 青海省| 甘孜| 齐齐哈尔市| 屏山县| 团风县| 延吉市| 南平市| 郯城县| 搜索| 梧州市| 黎城县| 梓潼县| 新河县| 永胜县| 三门峡市| 赞皇县| 鄱阳县| 福贡县| 白山市| 桐柏县| 石景山区| 伊川县| 鄱阳县| 武宣县| 渭南市| 琼结县| 新营市| 广平县| 巴马| 革吉县| 襄城县| 凌源市| 高平市| 澄城县| 安乡县|