java一路走來的感受

2019-11-18 14:38:44

字體：大中小

來源：轉載

供稿：網友

　　新手的第一個工程的總結（第一次寫文章，請前輩們指教）
napoleonn http://www.jdon.com Oct 1, 2004 3:42 PM 回復

孔子說：“學而不思則罔，思而不學則殆。”從我做項目的經歷，我深深感嘆古人鬧腔邸?

去年我畢業設計時候做的一個項目是畢業設計治理系統。當時老師給我們的要求是用jsp 和 javabean來實現。我主要負責項目建模和Javabean部分，后來負責數據庫的同學被SARS困在家不能返校，所以數據庫部分也由我來完成了。當時對java的知識是非常貧乏的，只有簡單的語法基礎，連JSP、 javabean都是第一次聽到過。不知道從哪里開始，于是就研究老師給的一個非常簡單的演示項目，首先覺得javabean是個比較簡單的東西，于是就先開始分析用戶需求。

需求怎么來描述呢？由于學校教育的局限，加上自己研究了很長時間高數，政治，英語（干什么用大家都明白吧），造成了知識的嚴重匱乏。我就以參加畢業設計人員為中心，建立他們的需求列表。但是這樣的需求描述是非常片面的，幾乎都是靜態的需求，而且很難設計幾個用戶的交互過程，和某些狀態的改變。而且這種需求是否真正符合需要是個問題，所以我馬上和同學一起設計web界面，目的很簡單，因為用戶的需求都是通過界面來實現的，對界面的設計能涵蓋最終提交用戶的功能，而且還能發掘很多非用戶的需求。這樣我在實現這些功能的時候會有數。在一年后當我仔細看過用例分析，uml后感覺是如獲至寶。心頭的結全部打開。

建模該怎么建？當時真是什么概念都沒有，雖然知道uml，但是僅僅知道皮毛。于是我就很簡單的從對象的角度考慮問題，首先找畢業設計治理系統中涉及的人員，這個是很明顯找出來的，涉及到學生，教師，治理員，進一步提取出項目對象，各個人員之間通訊的消息對象，畢業設計文檔對象，等等。接下來設計數據庫表，由于學校教數據庫的時候只有講述了ER圖到關系模式的轉化，而根本沒有講ODL到關系模式的轉化（現在看來，ODL應該更好，對理解O/R Mapping有更多的幫助。）于是就畫ER圖，建立各種表，設定主鍵，外鍵，等等。

我碰到的首要問題就是學生，教師，治理員該怎么辦，每一個對象建一個表，似乎也沒有什么問題。但是在建立消息對象的時候就有問題了，因為消息是要在學生，教師，治理員任意兩者都能傳送的，我建消息表的時候是這樣設計的：一個消息的內容，消息的發送人，消息的接收人（消息內容和發送人一個表，為解決冗余接收人單獨一個表），這樣這個消息就有很大的靈活程度了，消息發送人可以是三種角色間的隨便一種，更進一步，這樣的消息可以是系統生成的消息，而且接收者可以是隨便哪種角色。但隨之帶來的問題是：消息發送人、接收者該去參照誰呢?顯然填一個發送者、接收者的id是不夠的，必須連發送者的角色也填上。第二種方法，每個角色有一個收到消息的列表，讓它去參照單一的消息表id，這樣也能解決問題。第三種方法，把學生，教師，治理員合并成一個用戶表，那么消息發送人，接收人只要簡單的參照一個通用的用戶id了。這種合并子類的方法會造成教師，治理員的行有些null值，但是考慮到教師和治理員的數目遠遠小于學生的數目，所以這樣的冗余是忽略不計的。最后我還是選擇了最后一種方法。不過我還是覺的是對象模型向關系模型的一種妥協。

接著我著手設計javabean，訪問數據庫用的是單純的JDBC。因為我對前臺界面要訪問一個對象的哪些屬性是不了解的，事實上也不該了解。所以我只能從數據庫取出一個完整的對象，讓他來決定究竟要訪問哪些屬性。而且對對象的修改也是這樣，前臺修改好新的對象的屬性，我來進行更數據庫的同步。于是我的javabean就出現了這樣的方法：load（）、 store（）、 update（）、delete（）這樣的對象和數據庫表同步的方法。這在一年后的今天看來，實際上我已經自己做了一個O/R Mapping的工作了。當時自己做這樣的O/R Mapping是相當痛苦的事情，而且用的方法也是最粗淺的，就是整個對象更數據庫同步，即使沒有修改的屬性也同步，所以要同步的話，必須要先把對象從數據庫取出來，修改后再寫回。而且要求所有屬性必須是nullable的non-PRimitive類型。第二個問題，對表中的外鍵怎么反應到bean中？比如每個學生有一個輔導教師，在數據庫中很明顯學生表需要一個外鍵參照教師id，但是在StudentBean中教師屬性是寫Teacher對象呢，還是Teacher id值呢，按照面向對象，很明顯應該Teacher對象，但是我就覺得這是個多么heavy的事情呀！再想想教師情況，一個教師有一個Collection的Student對象是多么“重”！意味著load一個教師要load所有的students。于是我采用的方法是：還是用對象，比如teacher 的學生屬性，還是一個collection Student對象，同時提供了一個loadStudents（）的方法，load teacher對象的時候并不load 學生屬性，只有bean的用戶顯式調用loadStudents（）的時候才會加載一組student對象，這在現在看來似乎我自覺不自覺的實現了lazy loading？

現在審閱當時編寫的javabean，犯的最大最大的錯誤就是把data access object和business workflow混在一起了。比如把教師所有要調用的功能都放在教師對象里面，而有些功能有時是要涉及幾個bean的。現在看了簡直是慘不忍睹的設計，雖然當時也困惑過，但是卻沒有動動腦筋來解決，我現在看了session bean 的思路時，覺得是那么的愉快、自然。

當時困惑的還有關于JSP的處理，JSP只是負責顯示的，但是為什么一個JSP提交的數據要給另外一個JSP去處理呢？這是很不愉快的做法，于是有了最初的servlet做控制器的想法，但是當時顧不了研究那么多，也沒有最終實現，究竟前臺不是我負責的。當我現在知道了StrUCts，MVC Model2的時候，我以前的困惑都隨之解決。又一次感覺非常愉快。

上一篇：Java與.NET 的Web Services相互調用

下一篇：Java應用開發中JDBC接口技術的介紹