其他

什麼是介面？這些代碼結構有兩種角色：一是，定義一些行為提供給更多類型；二是：把焦點集中在要使用這些類型的類上。（This code construct has two dual role of defining behavior that applies to multiple types, and also being the preferred focus of classes that use those types）使用介面比實現讓你的軟體更容易擴充（Coding to an

分布式：電腦進程與進程間的通訊或同一台機器中的一個應用程式和另一個應用程式之間的通訊或區域網路中的程式通訊。Remoting使用的技術Xml：可以實現自描述SOAP：鮮蛋對象傳輸協議，目的是在Web上傳輸結構化類型化的資訊序列化：SerializableAttribute,ISerializable，目的是把對象轉換成在網路上可傳輸的格式       Remoting架構圖：       遠程對象的兩種含義：1、  操作遠程對象：使用Transparent Proxy2、 

                以私人化方式實現介面中的函數，我是第一次聽說，下面就來看看：                首先聲明一個介面：        public interface ITest    {        void Test1();        void Test2();}   接下來，我們再來實現介面    public class Test : ITest    {        public void Test1()        {           

我原來對於裝拆箱的理解只是停留在將實值型別轉化為Object類型，然後再轉換回來。實際上，在這個看似簡單的問題上還有一層更深的含義。實值型別和參考型別在執行個體化的時候是儲存在不同的空間中的，實值型別儲存在Stack上，而參考型別是儲存在Heap上，在裝箱的過程中實際上是將在Stack上的實值型別對象拷貝到Heap上，並以引用對象的儲存格式儲存，在這個過程中對所轉換的參考型別對象進行修改操作，Stack上的實值型別對象是不會變化的。而拆箱是將引用對象的值在拷貝回Stack上。下面我們來看一個例子

SqlServer當有where子句時，Sql從右向左查詢，如：Select * From Employee Where Sex='m' And Age>100 比 Select * From Employee Where Age>100 and Sex='m'Sql中的執行效率高到低：exists in join將查詢後的結果表整個插入表中：1、Select ... into TempTable2、Insert Into

前幾天在工作中發現SqlServer2000中的一個問題，就是建立好的視圖再用設計器開啟時有時會出現設計器中的代碼和原來的不太一樣。當時問題出現在原來在視圖中串連了兩張表T_Units和T_Units_1(T_Units的別名)但是再過了一段時間再開啟這張視圖時發現原來的T_Units不見了，出現了一張新的表叫做T_Units_2，是T_Units的另一別稱。原先視圖中引用的函數中傳遞的T_Units中的欄位變成了T_Units_1中的欄位，這樣導致了視圖查詢內容的錯誤。但是如果在視圖上雙擊查看

       今天發現我在項目中犯了一個錯，同一頁面中常常會出現這種情況，客戶點擊按鈕後，程式判斷是否有此記錄。如果存在則進行Update，否則進行Insert。當時為了省事，所以在頁面中存入一個ViewState，用來記錄記錄是否存在，而且自認為還少查了一次資料庫。但是忘記了操作成功後應該跳出這個頁面，結果出現一個問題，當進入這個頁面後，第一次操作，儲存了一個需要添加記錄的狀態，繼續儲存，因為沒有跳出頁面，所以程式一直保持添加狀態。       想想這個錯誤真不應該，以後再遇到這種問題可以有如

在看李建忠老師的Proxy代理模式課程的時候，聽他講了一些有關String類型和StringBuilder類型的內容。對這兩個類型的實現有了一些新的認識。在以前我看過一些有關String類型的資料，對於String類型來說，它給我的印象是小心的去用，否則記憶體上會產生大量的垃圾。關鍵問題在於對String對象的修改方面。當我們執行個體化一個String的對象後，在記憶體中為此對象分配一個空間。如下：       String strtest = “aa”;當我們修改strtest的值的時候，如：

UML五類圖（9種圖形）使用案例圖：從使用者角度描繪系統功能靜態圖：（類圖、對象圖、包圖），定義類及類間的關係行為圖：描述系統的動態模型和組成對象間的互動關係（狀態圖、活動圖表）互交圖：描述對象之間的關係（順序圖、合作圖）實現圖：構件圖，組件圖採用物件導向技術設計系統時，首先需要描述要求，其次根據需求建立系統的靜態模型，以構造系統的結構，第三，描述系統的行為（前兩點是UML中的靜態建模機制，第三點是動態建模機制）UML分為靜態建模機制和動態建模機制兩大類靜態建模機制包括：使用案例圖，類圖、對象圖

1、  CLR檢測方法中的參考型別，並產生一個內部資料結構，用於管理對參考型別的訪問。在這個內部資料結構中，參考型別的每一個方法實現都有一條對應的記錄，每條記錄容納了一個地址。對這個結構進行初始化的時候，CLR將每條記錄都設定成CLR內部包含的一個未文檔化的函數。這個函數被稱為：JITCompiler。被調用的JITCompiler函數負責將一個方法的IL代碼編譯成本地的CPU指令。2、 

       前一段時間又在做部署，由於程式（B/S）上有一些變動，在起始頁面要訪問當前Server的註冊表和MAC地址。程式在調試過程中沒有發現什麼問題，但是部署後卻出現了註冊表和MAC地址不可訪問的問題。記得我在寫《安裝部署中的資料庫打包和捷徑啟動瀏覽器》之後，曾經有一個朋友問過我這個類似的問題。當時由於我沒有接觸到所以也沒能給他很好的解決。不過這次，天上的石頭終於落到了我的頭上。我也遇到了這個問題。      

1、EnterPrise Library:可重用的程式塊庫，用於解決共性的企業級開發過程中所面臨的挑戰。2、EnterPrise Library中包含的7個Application Block:Caching,Security,Cryto(加解密)，DataAcess,Logging,Exceptions,Configuration。Configuration Application

         昨天，在工作中遇到了一個有關Session cookie的問題。以前沒有太注意過cookie，只知道它是用來存一些東西的，常常會產生一些垃圾檔案，常常要刪除。cookie實際上有兩種類型Session cookie和persistent cookie。         Session cookie 又叫 transient cookie，它被儲存在臨時的儲存空間中，瀏覽器關閉後不會保留         Persistent cookie 又叫 permenent cookie，

Spring架構套件含了很多特性，展現了Spring.NET的核心模組： Spring.Core：架構中最基礎的部分，它允許你配置程式使用依賴注入。它還包含一些附加特性： Expression Language：在運行時提供對對象有效查詢和操作Validation Framework：為業務對象提供複雜的驗證規則Data binding Framework：使用者介面架構實現資料繫結Dynamic

       前一段時間幫一個項目組做他們的項目，有幸瞭解了一下他搭建的架構。相比起以前所見過的架構，我覺得這個應該算是不錯的。大體結構如：             在編碼中體會到這個架構有以下幾個優點： 1、  層與層之間依賴於介面：UI依賴於IBLL，IBLL依賴於IDAL，這樣做在設計模式中叫做依賴倒置。也就是說依賴於抽象，而不是具體實現。如果今後的商務邏輯有變動可以不變程式的主體架構，靈活性較好。2、 

有時要在DataGrid中添加onclik事件，如；刪除某條記錄時，提示使用者確定刪除嗎的alert對話方塊，可以有如下寫法。private void grdPlan_ItemDataBound(object sender, System.Web.UI.WebControls.DataGridItemEventArgs e)  {   if( e.Item.ItemType == ListItemType.Item || e.Item.ItemType ==

      前幾天被時間類型給鬱悶了，我要做這樣一個工作，取出某天到某天的記錄，這些記錄都有一個欄位記錄著是什麼時候建立的，而且詳細到了秒。例如： Id CreateTime 1 2007-01-19 10:48:36 2 2007-01-19 23:35:36 3 2007-01-18 23:35:36 我要取出'2007-01-18'到'2007-01-19'的資料,其實這個需求並不難，所以當時直接就用Where CreateTime Between StartTime And

工作三年了，說實話也沒有好好的學習過物件導向的程式設計，只是一些工作中的感性認識加上自己所謂的一些理論。這段時間正在看一本書《Head First Object-Oriented Design and Analysis 》,書中的故事生動描述了OOA&D，藉此機會對自己學習到的東西做一下總結，並和大家分享。廢話少說，現在開始。        一、好的應用程式設計（Well-designed apps rock）        二、收集需求（Gathering Requirements） 

在這次項目開發中，我們對以前用的三層結構有進行了進一步的改變，除了使用Castle的Windsor容器來管理BLL層和DAL層，在資料的封裝和對資料的讀取上比以前更加物件導向。1、              對於BLL層和DAL層的類型，分別繼承各自的IBLL和IDAL，使用Windsor容器以注入的方式對其進行執行個體化，這一點和上次一樣，不再贅述。2、             

        相信每一個人都希望讓客戶滿意。而且現在已經知道寫一個好的軟體的第一步就是確定軟體所作的是客戶想讓它做的。但是你如何確定什麼是客戶想要的？如何確定客戶知道他們真正想要什嗎？        的確！在做項目項目的時候，我們常常被不確定的需求變化所困擾，當然如果說在開發時期要求需求一點不變化是不可能的，但是有些需求變化是致命的，會導致工作量成倍的上升，甚至是項目的失敗。現在有個情境，我們看看如何做才能很好的挖掘使用者的想法（這是編寫成功軟體的第一步）。        情景：有一個使用者要