鍵值對在MVC架構設計中的應用

鍵值對是強大的數據結構
服務器君一共花費了167.514 ms進行了5次數據庫查詢,努力地為您提供了這個頁面。
試試閱讀模式?希望聽取您的建議

程序其實就是兩個東西:代碼+數據,寫程序的時候也就是寫代碼操作數據的過程。做程序開發和做菜很像,數據就是食材,代碼就是廚藝,做出的軟件就是一道菜了,至于這個菜好不好吃,到底是看食材還是看廚藝了?呵呵,當我拋出這個問題的時候,我的第一反應是菜不好吃當然是手藝不好了,不知道其他童鞋是不是這么想的。認真想下,一道好菜一般都是二者必須兼備,當然不排除某一項突出也可以達到同樣的效果,但這種情況畢竟不是大眾化,而是屬于少數精英的,做軟件也是如此,代碼與數據是不可偏廢的。這里我要提的是數據。

根據我的經驗和知識(分類標準我一直想不太好,所以說是自己的經驗和知識),我把數據分為兩類:落地數據和不落地數據。

  • 落地數據:就是被持久化的數據,這種數據一般放在硬盤或是其他的持久化存儲設備里,例如:圖片、系統日志、在頁面上顯示的數據以及保存在關系數據庫里的數據等等,落地數據一定會有一個固定的載體,他們不會瞬時消失的。
  • 不落地數據:一般指存儲在內存或者是網絡傳輸里的數據,這些數據是瞬時,使用完畢就會消失,例如:我們在瀏覽器發送給服務器的請求;從數據庫讀取出來的一直到頁面展示前的數據等等。

寫過程序的人都知道,程序里對這兩種類型數據操作是有很大的不同的。

從MVC設計模式談起

java一個很重要的貢獻就是推出了mvc設計模式,mvc其實應該按vcm順序讀最好。v及view,主要是前臺展示的頁面;c及controller,控制層主要作用是接受前臺頁面數據,根據數據的不同調用后臺不同的業務模型,同時業務模型處理好的數據也要發送到controller,controller再分配給相應的前臺頁面;m及model,模型層專門負責操作業務模型。下圖很好的表達了mvc的理念:

隨著mvc模式的發展,現在流行的架構:view(視圖層)+controller(也叫action,控制層)+service(業務模型層)+DAO(數據訪問對象層)+數據庫的多層結構,如下圖:

紅線是用戶的請求;藍線是服務器響應用戶的請求。紅色和藍線也代表各層數據傳輸的流向。不管是傳統的mvc模式還是現在流行的多層架構, 各個邏輯層傳輸的數據都是不落地數據。

在java項目里,一般我們都是傳輸javabean,而這些javabean都是程序員根據實際業務需求自己定義的,例如下面一個典型的javabean:

public class User {
    
    private String name = "";
    private String sex = "";
    private String age = "";
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public String getSex() {
        return sex;
    }
    public void setSex(String sex) {
        this.sex = sex;
    }
    public String getAge() {
        return age;
    }
    public void setAge(String age) {
        this.age = age;
    }
}

各個邏輯層傳輸javabean對象的觀念一定會深入很多java程序員的人心,當一個項目開始,程序員都會吭哧吭哧的創建javabean對象,比如數據庫表映射的javabean,在struts1.2里還有頁面表達對應的javabean,做了這么多年這樣的javabean,現在我就思考,使用javabean真是最好的選擇嗎?

Nojavabean

我這里借用現在很流行的NoSQL的定義作為我文章第三部分的標題。javabean已經深入很多java程序員心理,甚至是很多程序員的習慣,其實它真的那么好用嗎?真的那么包治百病嗎?其實不盡然,下面我要列舉它的缺點:

  1. javabean的文件太多。一個java企業項目,都會使用orm,將數據庫映射為java對象,一般一張表對應一個javabean,甚至有些特殊情況還會歸并一些表做一個統一的javabean,如果這個系統有1000張表也就會有不少于1000個javabean,在原始的struts1.2里面還有和頁面表單字段一一對應的javabean,大伙可以想象下,這些毫無技術含量的java類也許會像病毒一樣去繁殖。
  2. javabean會增強各層之間的耦合度。每個層里運算結束,業務數據大多會被封裝成javabean對象,不同的業務封裝的javabean是不同的,mvc本來就是為邏輯層解耦做的設計,而傳輸介質卻是包含業務邏輯,如果碰到業務層級的修改,各個層之間都會有相應的結構性修改,增加了維護的成本。
  3. 我們至少會多維護一份數據字典。數據庫里的某張表一個字段叫USER_NAME,那么到了javabean里可能就變成了userName,當然我們在orm會有一個映射模型,但是隨著數據一層層傳遞,離數據庫越遠的數據,數據的本質也就越模糊,特別會給新手產生一定誤解,增加了軟件開發和維護成本。
  4. 這個是缺點是我的在實際項目里碰到的一個難題,我還沒把它總結成一個概括性的缺陷,但我相信會有童鞋碰到類似的問題。我在一個項目里做權限管理,因為某些數據的敏感性我們要做數據集的權限,比如某些人只能查看當天的數據,還有些人只能看當天數據前10條,另一些人只能看最近一個星期的數據,而且只有三個字段能讓他查看。由于權限管理是在該項目三期的任務,我們的權限設計是在原有的系統上進行開發,而且包含兩個不同項目,其中一個項目是使用javabean做傳輸介質,另一個我們用了另外的方式,最后這個javabean成了我們的夢魘,為了做一個通用解決方案,我們將用javabean作為傳輸介質的項目重構了一下,增加了不少工作量。
  5. mvc分層思想,其實是為了讓專業的人做專業的事,擅長做頁面的做頁面,擅長邏輯的做邏輯,按mvc思想項目開發往往是橫向分組的,但是實際開發中,沒人敢這么分配工作,究其原因就是層與層直接傳輸的介質并不統一。

既然我的標題是Nojavabean,not only javabean,那么就像NoSQL能彌足SQL數據庫的不足,以上的不足我們用什么技術來彌補了?答案就是:鍵值對。

萬能的MAP(鍵值對)

google的三篇論文帶來了云時代,用博大的胸懷改變了世界,而這里面最關鍵的東西就是map(鍵值對),key-value模式(后面簡稱kv)+數組我個人覺得基本可以表述這個世界的90%了。而且基本所有的語言都支持kv的數據結構,這件kv是多么強大的數據結構,世界就是被這個簡單方式而改變的。(本來我想談談kv在云計算存儲和計算的作用,作為本文主題的補充,但是時間限制,大伙可以自己查閱下相關資料)。

我的替代數據模型就是用map作為數據傳輸介質,讓我產生這個想法的源頭是三個技術:mapreduce,ibatis和json;我們中心很重視hadoop技術,我們這里經常做hadoop相關技術分享,聽來聽去都有什么mapreduce,都是map,map;而我們現在公司的項目都是用ibatis做orm,當時表很多,我一時偷懶不是所有的ibatis配置文件都和javabean一一對應,只是返回一個map對象,如果是列表查詢就是List<Map>,沒想這么做居然有意外的收獲,因為頁面數據我們都是封裝成json對象,json其實也是一個鍵值對的模型,數據到了action也是被傳化成了map,所有返回值一樣,居然提升了整個開發的效率,而且項目里面少了javabean對象,顯的清爽多了。

下面我總結下map的好處,在文章第三部分寫道了javabean的缺點,這些缺點倒過來看就是map的優點了,我這里就不再復述了:

  1. map取值方式是用key,key是字符串,是可以隨時定義,而javabean是通過定義的方法讀取,如果使用map會將傳輸數據的業務屬性封閉在map內部,這樣帶來了操作的方便。不管什么技術從map取值的方式是統一的:
  2. // javascript里面json
    obj.XXX或者obj[XXX]
    
    // java里的map
    map.get(XXX)或map.put(XXX)
    
  3. map技術幾乎在所有的主流技術里面都有,那么用這種數據結構作為傳輸介質是跨平臺的
  4. map數據結構算法很成熟,做復雜計算是十分方便。

本文地址:http://www.824886.live/librarys/veda/detail/121,歡迎訪問原出處。

不打個分嗎?

轉載隨意,但請帶上本文地址:

http://www.824886.live/librarys/veda/detail/121

如果你認為這篇文章值得更多人閱讀,歡迎使用下面的分享功能。
小提示:您可以按快捷鍵 Ctrl + D,或點此 加入收藏。

大家都在看

閱讀一百本計算機著作吧,少年

很多人覺得自己技術進步很慢,學習效率低,我覺得一個重要原因是看的書少了。多少是多呢?起碼得看3、4、5、6米吧。給個具體的數量,那就100本書吧。很多人知識結構不好而且不系統,因為在特定領域有一個足夠量的知識量+足夠良好的知識結構,系統化以后就足以應對大量未曾遇到過的問題。

奉勸自學者:構建特定領域的知識結構體系的路徑中再也沒有比學習該專業的專業課程更好的了。如果我的知識結構體系足以囊括面試官的大部分甚至吞并他的知識結構體系的話,讀到他言語中的一個詞我們就已經知道他要表達什么,我們可以讓他坐“上位”畢竟他是面試官,但是在知識結構體系以及心理上我們就居高臨下。

所以,閱讀一百本計算機著作吧,少年!

《設計模式:可復用面向對象軟件的基礎》 Erich Gamma (作者), Richard Helm (作者), Ralph Johnson (作者), John Vlissides (作者), 李英軍 (譯者), 等 (譯者)

《設計模式:可復用面向對象軟件的基礎》是引導讀者走出軟件設計迷宮的指路明燈,凝聚了軟件開發界幾十年設計經驗的結晶。四位頂尖的面向對象領域專家精心選取了最具價值的設計實踐,加以分類整理和命名,并用簡潔而易于重用的形式表達出來。本書已經成為面向對象技術人員的圣經和詞典,書中定義的23個模式逐漸成為開發界技術交流所必備的基礎知識和語匯。

更多計算機寶庫...

云南快乐十分走势一定牛 贵州11选5最高遗漏 最近股票大盘连跌 _百家乐网 四川快乐12今天开奖结 股票开户证券公司哪家好 甘肃十一选五最大遗漏全部 时时彩龙虎和全天计划 黑龙江11选5联网软件 上海快三预测号码今天 深圳股票配资平台