Month: March 2011

  • Web之頁面處理-內容填充

    XmlDocument xDoc = new XmlDocument();         try         {             xDoc.Load(“xml文件路徑”);             XmlNode xNode = xDoc.SelectSingleNode(“xpath語法”);             if (xNode != null)             {                 xNode.InnerText = “秋色園:cyqdata”;//用戶名填充                 if (xNode.Attributes[“href”] == null)//用戶名鏈接填充                 {                     XmlAttribute attr = xDoc.CreateAttribute(“href”);                     xNode.Attributes.Append(attr);                 }                 xNode.Attributes[“href”].Value = “http://www.cyqdata.com/“;             }         } 使勁想啊:壹個節點填充,需要寫這麽長的代碼,開發起來那得是何等相當的吃力?對於Xml操作賦值,還需要考慮使用:<![CDATA[帶特殊字符的內容]]>,來解析復雜內容。

  • Oracle 通過alter table增刪改列的語法

    alter table tablename add (column datatype [default value][null/not null],…);     alter table tablename modify (column datatype [default value][null/not null],…);     alter table tablename drop (column);     這裏分別是使用alter table 來增加、刪除和修改壹個列。     下面是具體的例子:     create table test1     (id varchar2(20) not null);     alter table test1     add (name varchar2(30) default ‘無名氏’ not null);     alter table…

  • 利用C#實現標準的Dispose模式

    我們已經知道了處置那些占用非受控(unmanaged)資源的對象的重要性,現在應該編寫資源管理代碼來處置那些包含非內存資源的類型了。整個。NET框架組件都使用壹個標準的模式來處理非內存資源。使用妳建立的類型的用戶也希望妳遵循這個標準的模式。標準的處理模式的思想是這樣的:當客戶端記得的時候使用IDisposable接口釋放妳的非受控資源,當客戶端忘記的時候防護性地使用終結器(finalizer)。它與垃圾收集器(Garbage Collector)壹起工作,確保只在必要的時候該對象才受到與終結器相關的性能影響。這是處理非受控資源的壹條很好的途徑,因此我們應該徹底地認識它。     類層次體系中的根基類(root base class)必須實現IDisposable接口以釋放資源。這個類型還必須添加壹個作為防禦機制的終結器。所有這些程序都把釋放資源的工作委托給壹個虛擬的方法,衍生的類可以根據自己的資源管理需求來重載該方法。只要衍生的類必須釋放自己的資源,並且它必須調用該函數的基類版本的時候,它才需要重載這個虛擬方法。     開始的時候,如果妳的類使用了非內存資源,它就必須含有壹個終結器。妳不能依賴客戶端總是調用Dispose()方法。因為當它們忘記這樣做的時候,妳就面臨資源泄漏的問題。沒有調用Dispose是它們的問題,但是妳卻有過失。用於保證非內存資源被正確地釋放的唯壹途徑是建立終結器。     當垃圾收集器運行的時候,它立即從內存中刪除所有不帶終結器的垃圾對象。所有帶有終結器的對象仍然存在於內存中。這些對象都被添加到終結隊列,垃圾收集器引發壹個新線程,周期性地在這些對象上運行終結器。在這些終結程序線程完成自己的工作之後,就可以從內存中刪除垃圾對象了。需要終結的對象在內存中停留的時間比沒有終結器的對象停留的時間長很多。但是妳別無選擇。如果要使程序有防護性,在類型包含非受控資源的時候,妳必須編寫壹個終結器。但是也不用擔心性能問題。下壹步確保了客戶端避免與終結相關的性能開銷。     實現IDisposable接口是壹種標準的途徑,它通知用戶和運行時系統持有資源的對象必須及時地釋放。IDisposable接口僅僅包含壹個方法:     public interface IDisposable     {     void Dispose( );     }     妳對IDisposable.Dispose()方法的實現(implementation)負責下面四個事務:     1、釋放所有的非受控資源。     2、釋放所有的受控資源(包括未解開事件)。     3、設置標誌表明該對象已經被處理過了。妳必須在自己的公共方法中檢查這種狀態標誌並拋出ObjectDisposed異常(如果某個對象被處理過之後再次被調用的話)。     4、禁止終結操作(finalization)。妳調用GC.SuppressFinalize(this)來完成這種事務。     通過實現IDisposable接口妳完成了兩個事務:妳為客戶端及時地釋放自己持有的所有受控資源提供了機制;妳為客戶端提供了壹種釋放非受控資源的標準途徑。這是壹個很大的進步。當妳在類型中實現了Idisposable接口的時候,客戶端可以避免終結操作的開銷,妳的類就成為。NET世界中的”良民”了。     但是在妳建立的這種機制中仍然存在壹些問題。怎樣在衍生類清理自己資源的時候同時也讓基類能夠清理資源?如果衍生類重載了終結操作,或者添加了自己的IDisposable實現,那麽這些方法必須調用基類,否則,基類就不能正確地進行清理操作。同樣,finalize(終結操作)和Dispose參與分擔了壹些相同的職責。Finalize方法和Dispose方法的代碼幾乎相同。而且在重載接口函數後並不像妳預料的那樣工作。標準的Dispose模式中的第三個方法是壹個受保護的虛擬輔助函數,它分解出這些共同的事務,並給衍生類添加壹個用於釋放資源的”鉤子(hook)”。基類包含了核心接口的代碼。作為對Dispose()或終結操作的響應,該虛擬函數為衍生類清除資源提供了”鉤子”:     protected virtual void Dispose( bool isDisposing );     這個重載的方法實現支持finalize和Dispose的必要事務,由於它是虛擬的,它為所有的衍生類提供了壹個入口點。衍生類可以重載這個方法,為清除自己的資源提供適當的實現,同時還可以調用基類版本。當isDisposing為真(true)的時候,妳可以清除受控和非受控資源,當isDisposing為假(false)的時候,妳只能清除非受控資源。在這兩種情況下,妳都可以調用基類的Dispose(bool)方法,讓它清除自己的資源。     下面有壹個簡短的例子,它演示了妳在實現這種模式的時候所提供的代碼框架。MyResourceHog類演示了實現IDisposable接口、終結器的代碼,並建立了壹個虛擬的Dispose方法:     public class MyResourceHog :…