1.在View擷取一個JSON資料可以有三種方法: A.提交到一個aspx頁面,頁面輸出json格式的資料 如: Response.ContentType = "application/json"; Response.Write("{result: 'true'}"); B:提交到一個ashx頁面,格式同上
當我們需要從一個字串(主串)中尋找一個模式串(子串)時,使用KMP演算法可以極大地提升效率。KMP是一個高效的字串匹配演算法,它巧妙的消除了在匹配的過程中指標回溯的問題,關於KMP演算法的更多介紹,可以參考這裡。原始的KMP演算法適用的對象是字串的匹配搜尋,其實針對任意類型的串(實際上就是一個數組)的子串搜尋,都可以使用KMP演算法。比如,我們可能需要在byte[]中尋找一個特定的位元組數組,這同樣可以使用KMP演算法來提升匹配效能。為此,我實現了泛型的KMP演算法,使之可以應用於任意類型的串匹
最開始的時候我是在action裡迴圈數組,拼接了一個帶HTML格式的字串,後來想到這樣的話資料和HTML耦合太高了,在介面上無法修改HTML樣式。 於是我就換了種方法,action只提供給前台json數組,前台用一個html模板,迴圈把json裡的資料填入到模板裡就行了。 核心代碼如下: //擷取評論內容 function getComments(pageindex) {
1 MVC設計模式簡介 MVC結構是為那些需要為同樣的資料提供多個視圖的應用程式而設計的,它很好的實現了資料層與展示層的分離。MVC作為一種開發模型,通常用於分布式應用系統的設計和分析中,以及用於確定系統各部分間的組織關係。對於介面設計可變性的需求,MVC(Model-View-Controller)把互動系統的組成分解成模型、視圖、控制器三種組件。 視圖組件把表示模型資料及邏輯關係和狀態的資訊以特定形式展示給使用者。它從模型獲得顯示資訊,對於相同的資訊可以有多個不同的顯示形式或視圖。
在GOF的設計模式中沒有簡單工廠,而是將其作為Factory 方法的一個特例加以解釋的。可以這樣理解,簡單工廠是參數化的Factory 方法。簡單工廠的作用是執行個體化對象,而不需要客戶瞭解這個對象屬於那個具體子類。優點:可以使使用者根據參數獲得對應的類的執行個體,避免了使用者直接執行個體化類,降低了耦合性。缺點:可執行個體化的類型在編譯期間已綁定,如果增加新類型,則需要修改工廠。簡單工廠需要知道所有要產生的類型,當子類過多或者子類層次過多時不適合使用。
作為.NET平台上的開發人員,要開發出一個像樣視訊交談系統,非常艱難,這不僅僅是因為.NET對多媒體的支援比較有限,還因為網路語音視頻這塊涉及到了很多專業方面的技術,而.NET在這些方面的沉澱更是稀少。OMCS的出現將使得這一狀況完全改觀,它把所有底層的、複雜的、繁瑣的細節都封裝在了內部,提供給您一個易用而又強大的介面。OMCS
5. 描述解決方案 如果Forces描述非常吸引人,那麼使用者會迫切希望知道解決方案。軟體開發人員通常希望採用圖示法描述解決方案,因為一張圖勝過千行字。然而需要注意的是,如果採用圖示,一定要確保使用者知道圖示的含義。如果採用UML等標準的圖示語言,一定要準確合理;如果是非標準的圖示,一定要註明圖例的含義。還需要注意的是,不僅僅要描述靜態模型,還要描述動態模型。 儘管圖示非常有用,但仍代替不了文字描述。對圖中的元素一定要進行適當描述,以避免對圖的。很顯然,如果不加描述,
1.前提
這幾天一直在研究各種各樣的設計模式,在學習適配器模式、橋接模式和面板模式模式的時候,發現他們之間存在著一定的關係,實際上模式不適單一存在的,在我們的現實編程生活中往往是幾種模式結合使用的。1.適配器模式與橋接模式的區別和聯絡 適配器模式和橋接模式都是間接引用對象,因此可以使系統更靈活,在實現上都涉及從自身以外的一個介面向被引用的對象發出請求。
1.裝飾模式的概述2.1 什麼是裝飾模式 在不改變對象的前提下,動態增加其功能,即我們不希望改變原有的類,或採用建立子類的方法增加功能,這種情況下需要採用裝飾模式。2.2結構 修飾一個對象後,其介面不應該發生變化;否則這個對象不能被原有調用者使用,修飾失去了意義。由此引出了裝飾模式結構最重要的一點,即裝飾者和被裝飾者具有相同的介面。換句話說,動態增加的功能不應該破壞已有的介面。裝飾模式的結構如所示。
到今天為止,wowMovies項目已經經曆了2次大的變動.在06年底我開始動手做這樣的東西,後來沒有繼續下去.等到siverlight推出我看到那高清的播放畫面,我覺得這就是我想要的東西. 08年底,我開始完成後台管理模組,前台山寨了 魔獸官網 的介面,那個功能基本完成了.不過這始終只能做為一個技術研究,不能投入實用,一個視頻網站太燒錢了. 09年3月份,.net mvc終於出了1.0正式版,為了學習新技術,我把wowMovies用.net mvc重新實現一邊.
1.引言 在商品房銷售系統中,房屋資訊是基礎資訊。在系統運行前必須輸入房屋的各種資訊到系統中,這是一項枯燥的重複勞動。如果讓使用者重複輸入房間的類型、面積和衛生間樣式,這個系統肯定尚未運行就夭折了。實際上,一個小區樓盤的樣式並不多,不同的只是樓號。另外,樓盤中的房間類型也非常有限,從而為解決輸入問題提供了啟示。樓盤的邏輯結構。
1.概述1.1意圖 單件模式保證應用只有一個全域惟一的執行個體,並且提供一個訪問它的全域訪問點。1.2使用場合 當類只能有一個執行個體存在,並且可以在全域訪問時。這個惟一的執行個體應該可以通過子類實現擴充,並且使用者無須更改代碼即可使用。 我們前面介紹的工廠類經常被執行個體化為全域惟一的單件,可能的單件還有管理日誌的對象、關鍵字產生對象和外部裝置介面對象等。1.3結構
文章目錄 1.3/N層架構2. “架構+外掛程式”架構3.地區分布式架構 經過這幾年的積累,在系統架構方面逐漸積累了一些自己的經驗,到今天有必要對這些經驗作個小結。在我的架構思維中,主要可以歸類為三種架構模型:3/N層架構、“架構+外掛程式”架構、地區分布式架構。一.三種架構模型1.3/N層架構 這是經典的多層架構模型,對於稍微複雜一點或特別複雜的系統,不使用分層架構是很難想象的。是經典的3層架構:
1.概要1.1意圖 將複雜物件的構建與表示分離,使得同樣的構建過程可以建立不同的表示。需要注意如下幾點。(1)構建與表示分離:表明產生器模式的結構,構建過程被封裝在導航器中,產生器則負責實現具體的表示。(2)同樣的構建過程:產生器模式關注的是構建過程,即構建過程是相同的。(3)不同的表示:產生器模式並不在意產生對象的結果,其構造的產品不一定有相同的類型。1.2使用場合
1.前言1.1概要 簡單工廠的作用是執行個體化對象,而不需要客戶瞭解這個對象屬於哪個具體的子類。 在GOF的設計模式中並沒有簡單工廠,而是將其作為Factory 方法的一個特例加以解釋。可以這樣理解,簡單工廠是參數化的Factory 方法。1.2使用場合 簡單工廠執行個體化的類具有相同的介面,類類有限並且基本不需要擴充時,可以使用簡單工廠。例如,資料庫連接對象,常用的資料庫類類可以預知,則使用簡單工廠。1.3效果
1.目的 提供一個建立一系列相關或互相依賴的對象的介面,而無須指定其具體的類。2.使用範圍 在以下場合可以使用抽象工廠。(1)一個系統要獨立於其產品的建立、組合和表示時。(2)一個系統要由多個產品系列中的一個來配置時。(3)需要提供一個產品類庫,而只想顯示它們的介面,而隱藏其實現時。3.抽象工廠的結構 抽象工廠的結構。
GOF指出了設計模式能夠解決的問題,但是設計模式也不是萬能,什麼都可以做,肯定有他不能做的事情或者是用了設計模式卻適得其反。1.設計模式不是法則 模式理論的精髓之一就是模式的使用是有前提和代價的,模式是在某種前提下,綜合各方面的因素考慮得出的結果。即在使用模式時總要付出一定的代價的,當然這種代價是可以接受的。如果某個模式在所有場合的使用都是必然的,那麼它就不叫設計模式了,而是必須遵守的法則。例如“面向借口,而非實現編程”是法則而非模式。
GOF指出了設計模式可以解決的問題,這些問題存在時可以考慮使用設計模式。1.通過顯示指定類建立對象 建立對象的最簡單方法是採用New關鍵字直接調用類的建構函式,例如我們聲明一個針對SQL Sever的資料庫連接:IdbConnection dc=new SqlDataConnection();產生的問題是當我們希望採用Oracle資料庫時,代碼就要發生變化。更糟糕的是,針對不同的資料庫,需要不同的代碼版本。