其他

1）對於Entity的支援相對來說比較好，自動產生的實體如果以Entity為基類，可以掛接屬性改變事件，這個非常有用，但如果產生的實體以ComplexObject為基類，則沒有這個好處；2）ComplextObject對於服務端得實體要求不是很嚴，不像要產生Entity為基類的實體那樣，不能在字典中含有實體，字典中的類型只能是基本類型；3）在服務中如果要暴露以Entity為基類的實體，必須有一個不帶Invoke的標籤的查詢方法，否則，系統會將暴露該實體集合的方法之一看成是這樣的方面，如果你的實體

public class TreeNode { public string Key { get; set; } public object Data { get; set; } public TreeNode Parent; public List<TreeNode> Children { get; set; } public TreeNode(string Key,object Data) {

我們知道要實現計算系統中計算部分的能力的提升，無外乎就兩種辦法，一是提高單台計算裝置的能力，二是增加計算裝置。我們知道，單台裝置計算能力的提升總是有限度的，因此要實現雲端運算中計算能力的提升，增加裝置就是唯一的選擇。增加裝置能夠提升計算能力和一個應用能否利用這種增加的計算能力是兩回事，而要能利用這種增加裝置而帶來的計算能力就需要應用支援分散式運算。因此，要達到雲端運算的計算能力隨需應變的能力，有兩個很基礎的條件，一是電腦虛擬化，二是應用的分散式運算支援。因為在雲端運算下，不再具有物理的邊界條件，

單例模式的目的是保證類在系統中只被執行個體化一次,由該唯一的執行個體來為系統提供服務.單例模式主要用於保證服務的統一,比如擷取統一的編號服務,模仿Oracle的序列產生等.但單例的使用需要謹慎,特別是在需要作負載平衡的地方,因為這種程式級的單例模式實際上只能保證在一個應用中為單例.如果被多個應用載入,還是會被多次執行個體化.     同時如果採用懶漢式還需要注意安全執行緒.    

 現在的silverlight用戶端綁定支援索引器方式，比如VM有屬性:public Dictionary<string,string> KeyValues{get;set;}在後台CS中我們要訪問某個key的值的方式是:KeyValues["XXXX"],其中XXXX是key.而在xaml中可以如下訪問：Text="{Bindings Path=KeyValues[XXXX]}"只要索引器本身支援get,set還可以實現雙向繫結。但這個雙向有一個缺陷，就是如果KeyValues["

原來搞WCF RIA,限制多點，這次把WCF好好複習一下，準備做分布式調度用。1、WCF服務中的合約，可施加於介面，而非類；2、WCF服務中如果私人方法被施加了操作屬性，則遠程可以調用，這樣做的好處可以讓有些方法僅對遠程調用有用，而本地調用無效；3、介面和實體模型可單獨放在一起，供用戶端和服務端共用；4、WCF支援多種協議，而且支援雙工通訊，這是其優勢;例子：A）介面using System;using System.Collections.Generic;using

顧名思義，橋的作用就是將兩條相互獨立的路橋接到一起，而兩條路可以保持各自的相對獨立。在程式設計中，“橋”模式中的橋只是一種形象的比喻。根據橋模式的定義，橋模式實現了一個主題（可以是一個類，也可以是一中設計上的概念）的抽象部分和實現部分的分離(有的地方定義為抽象與具體行為的分離）。抽象部分的基類和實現部分的基類充就當著橋（介面對接）的作用，而抽象部分的子類和實現部分的子類就是橋兩邊的路，可以各自相對獨立的發展（變化）（之所以是相對獨立，從實現上來講就是這種變化不能脫離最終能夠實現橋接這個目標）。 

演算法代碼如下：public class HuffmanNode { public char Char { get; set; } public int Frequency { get; set; } //用於構造哈弗曼樹 internal HuffmanNode LeftChild { get; set; } internal HuffmanNode RightChild { get; set; } //

在本篇中，我們不僅示範實體的結構，而且我們利用集合屬性來打造萬能實體（類似於DataTable)。 下面是代碼：1）首先我們定義Column,主要提供欄位列資訊：DynamicDataColumn.csusing System;using System.Collections.Generic;using System.Linq;using System.Text;namespace MEntities{    [Serializable]    public partial class

很多東西都是混熟了,就慢慢瞭解了,慢慢瞭解了就慢慢理解了,慢慢理解了就會慢慢懂得.學習新東西尤其如此.其實有個幾次準備學習linux的想法,但大多都在裝個系統,敲幾個命令後就結束了,這次,決定再學Linux,於是每天堅持用個把小時,慢慢 的也開始有點感覺了...其實Windows也沒真正學過,不也是混熟的嘛;搞了這麼多年編程,設計和架構,其實也都是混熟的;要想學什麼,不管怎麼樣,先跟它混熟...,因為只是混,不會有太多的壓力,反而有利於接近,瞭解,然後理解...當然,在CSDN寫部落格也是這樣,

在這個系列裡我們將學習一般業務系統的整個過程，涉及到從資料庫一直到silverlight頁面的各個方面。樣本中遵循我一貫的風格，不採用任何第三方架構。但為了簡單起見，這裡不考慮多種資料庫支援（其實多種資料庫支援在可以利用預存程序的情況下，非常簡單，封裝一個資料庫訪問層即可），同時為了減輕貼圖的壓力，我們假設各位對於基本的silverlight的程式建立沒有任何問題。下面是整個程式的大致架構： 1)資料庫：樣本中採用sqlserver.2)應用服務層：分為4.5層，其中實體層是大部分層次都需共用的

採用微軟提供的silverlight+wcf ria service+ado.net

  比較常見的比較排序有插入排序，選擇排序，冒泡排序，合并排序，快速排序，堆排序等方法，這些排序的期望時間T(n)>O(nlgn).線性排序的方法有計數排序，基數排序，桶排序。排序方法的選擇應該考慮幾個比較重要的特性：時間複雜度，空間複雜度，穩定性，常數因子，演算法實現難度，輸入依賴性等。綜合這些因素來講，在實際應用中，線性排序未必就比比較排序要好。下面是常見的排序實現（計數排序和快速排序可參見前面的博文）: public class MySort {

建立模式的目的就是為瞭解決使用和生產責任分離,當然能使用這種模式的前提就是使用者並不關心"產品"的建立邏輯和過程,使用者只需要對建立的結果進行使用.在這種情況下,將使用和建立分離就增加了程式的靈活性,因為"產品"的構建對使用者來說是透明的,如果需要對建立過程增加功能(比如增加建立許可權檢查),不會影響到使用者的使用.       模式的應用有兩個基本的目的,一是複用,二是適應變化.而且這兩個目的在很大程度上也是統一

在日常生活中，我們時常會遇到一些相容性的問題，比如我的筆記本的電源插頭就是歐標的，在很多場合我都沒法用，買一個可以用的插座當然是可選手段，但到那裡去都拿這麼大個傢伙一是不方便，二也未必有地方可以插，所以我只好買個電源適配插座帶在身上。再比如電腦的輸入電壓一般都只有20伏左右，而日常電源基本都是220伏，所以就需要一個電來源配接器，來降低電壓。這些都是為瞭解決不同標準之間的相容性問題。設計模式中的適配器模式就是我們在設計中用來解決標準相容性問題的一種重要手段。適配器的角色分為適配器，適配對象和適配

採用最大堆實現的優先隊列，QueueElement是隊列元素類，包含一個衛星資料成員和一個權重Key值: public class QueueElement<T> { public int KeyValue{get;internal set;} public T Element{get;private set;} public QueueElement(T Item,int KeyVal) {

前提是世界是流通的，你可以用行政手段隔斷一時，但不會隔斷一世：1）貨幣是財富交換的中介，是財富的計量單位,貨幣數量M與財富數量F之間的關係:M=αF,其中α為係數，α等於1代表同通縮也不通漲，大於1就是通脹，小於1就是通縮。2）人民幣￥和$關係：β$=￥,β是匯率，體現的是不同貨幣購買力的差異；按等價交換原則，假設1元人民幣可買1個單位的財富，那麼買同樣1個單位財富需要的美元數是β,β這個係數就是兩種幣別之間的匯率。當然這是正常情況，實際上還會受到需求的影響。如果美國對中國的財富需求比較多，那麼

轉載一篇關於字串匹配演算法ZZL的論文， 圖片有點問題，將就著看吧，這個演算法其實很簡單！就是先統計特徵串的首字元在主串中中的位置，然後每次匹配都是從儲存的位置開始。在平攤意義下，還是很有效果的。  字型大小：大 中 小 一種可做特殊用途的字串匹配演算法紀福全 朱戰立(西安石油大學電腦學院，西安 710065)    摘 要 

包括，選擇最大值，最小值，選擇第k大元素的演算法。其中選擇第k大元素包括隨機播放演算法和最壞線性時間演算法。選擇演算法有一個假設就是輸入的元素都不相同，如果是輸入序列有重複的，那麼這些演算法都不適用。由於輸入序列條件苛刻，因此實際應用中感覺很難用，還不如老老實實先排序，然後再遍曆尋找。下面是演算法實現代碼：public class MySearchs { /// <summary> /// 擷取最大值和最小值. ///

在前面的博文中，如果要能進行修改，都是用strValue進行綁定的，但這隻說明string類型的在datagrid自動產生的列中是可以編輯的，用Object進行綁定一樣也可以編輯，但需要進行一定的處理，而且用strvalue,intvalue分別綁定也不符合開發友好原則，我在樣本中有Object屬性，而且也進行了通知屬性處理，這裡我們利用一個convert來處理object類型的綁定，根據欄位內建的資料類型，其實我們可以做得很通用化。下面是代碼(其它代碼見樣本):1）ObjectAutoConv