其他

接上文對檔案系統的操作：對於檔案目前內建3中支援對象：XML、TEXT、CONFIG檔案，分別位於類庫XMLProvider、TextProvider、SuitConfigProvider中，大家可以自己調用，檔案操作大多使用靜態操作。對config檔案的操作：這裡還要介紹一SuitConfigProvider類庫中的GetItem、GetSection、AppendItem、RemoveElement

如果在開發應用的時候沒有使用任何持久層架構，而是直接使用jdbc 的api編程的話，大家最長使用的就是ResultSet介面進行資料的讀取了，但是大家也會覺得很不方便，因為ResultSet是線上的資料集，在讀取資料的過程中不能斷開資料庫聯結，只有讀取資料完成後才能close掉相關對象。其實java也提供了離線的資料集，那就是RowSet介面以及相關的

接上文IsLine FrameWork Provider介紹其中IsLine.Data、IsLine.AppLog是我要重點介紹的，不過現在先來簡單說說各個Provider的作用。DataProvider與其他架構一樣，DataProvider為項目提供了與資料庫互動的能力，它的優點在這裡不再闡述，這裡只說一下它與其他架構的資料訪問層不同的地方。DataProvider同時相容SQL

接上文ILFW架構以最底層為基礎，層層堆疊，上層一依賴於下層提供的服務，並實現其派發的介面，形成完整的FrameWork，不過由於時間原因，有些

在託管記憶體管理中，“泄漏”意義不同與傳統 Native 應用中的忘記顯式釋放（delete/delete[] 等）不同，當然對於非託管資源之類（如控制代碼等）還是需要在 Finalize （析構方法等同於 Finalize）方法中顯式釋放的，在託管記憶體管理中“泄漏”對象執行個體指的是，由於與 Root 對象集中的對象存在本應斷開的參考關聯性，而讓 GC

Chain.NET（又名NChain）是職責鏈模式在.NET和Mono平台上的一個實現。它的0.1版本（已可以在SourceForge中訪問）結合了標準的職責鏈模式以及命令模式，目的是“為基於命令處理的功能提供一個方便而又靈活的解決方案”。NChain鬆散地基於Java平台上的Jakarta的Commons

使用J2SE API讀取Properties檔案的六種方法：1.使用java.util.Properties類的load()方法樣本：InputStream in = lnew BufferedInputStream(new FileInputStream(name));Properties p = new Properties();p.load(in);2.使用java.util.ResourceBundle類的getBundle()方法樣本：ResourceBundle rb =

共用的分頁類,使用非常簡單,試合初學者使用,但效率較低,使用的是PagedDataSource分頁public PagedDataSource GetPagedDataSource(DataSet MyDataSet,int PageSize,int PageNum,string AspxName,Label PageLable){PagedDataSource PDS=new

今天繼續我們的WCF分布式開發必備知識系列文章的第4節:Web Service.前3節我們分別介紹了MSMQ訊息佇列\.Net Remoting\Enterprise Services三個相關的技術.並且給詳細注釋的代碼實現例子.先介紹一下本節的文章組織圖,首先還是介紹1.Web Service的基本概念2.優勢和缺點3.使用Web Service的場合4.安全問題5.實現代碼部分最後是總結.初學者就當入門資料,高手就當溫習,也歡迎提出意見.那現在我們就開始今天的學習,網上關於Web

struts.properties檔案在WEB-INF/classes目錄下存放。這個檔案用來配置Struts2系統的一些基本規約，所有在struts.properties中配置的內容都可以在struts.xml中配置，或者web.xml中在struts2 filter中配置，例如：Struts.properties中的如下配置：struts.i18n.encoding=UTF-8相當於struts.xml中的如下配置：<constant

上一節我們學習了網路分布式編程中的MSMQ訊息佇列技術.本節我們將學習分布式編程的另外一個重要的技術.Net Remoting,文章的結構還是先討論基本概念,再來探討具體的技術實現,希望能和大家一起交流學習..Net Remoting技術，我們可以將其看作是一種分散式處理方式。作為應用程式之間通訊的一種機制,.Net

在資料庫應用程式中最基本的操作是CRUD（建立/讀取/更新/刪除)，這4個操作構成了資料庫應用程式的基石。在單機時代，一個資料庫只由一個應用程式使用，這樣CRUD操作並不會帶來什麼負面影響，但當進入網路時代後，這一切都發生了改變。由於網路資料庫程式一般是由多個用戶端同時操作一個資料庫，因此，傳統的CRUD操作將變得不再安全。因此，這個問題將引出本文的中心內容：事務。通過事務可以使傳統的CRUD操作適應網路資料庫應用。本文分為三個部分。第一部分討論了Hibernate如何管理事務和會話。第二部分描

故事是這樣發生的:越來越多的使用者在網站購買了東西,每成功訂下一個定單,就要向使用者的郵箱發送一封EMAIL。當郵件正在發送時,佔用的資源會非常多，使用者也需要等待，使用者越多,這樣使用者頁面上的等待時間就會變得很長，為瞭解決這個問題，決定把發送ＥＭＡＩＬ和簡訊的都改成非同步執行的。非同步發送郵件，有兩種做法；一種是大家在網上一搜就能找到一堆的發送方法，這種方法都是在發送email的時候再進行非同步作業，如這篇文章（）中寫到的。但是這種方法在我這裡需要的成本太高，因為發送郵件的方法是封裝好的，不

實現具體步驟：1．確定視頻檔案的位置MediaLocator mrl=new MediaLocator(new java.lang.String(“檔案路徑和檔案名稱”));2．利用Manager.createPlayer建立一個播放器（Player）Player

.NET3.5多了個HasSet<T>用來儲存集合。從名稱可以看出，它是基於Hash的。可以簡單理解為沒有Value的Dictionary<TKey,TValue>。HashSet<T>不能用索引訪問，不能儲存重複資料，元素T必須正確實現了Equals和GetHashCode。那它的優勢是什麼呢？檢索的效能。簡單的說它的Contains方法的效能在大資料量時比List<T>好得多。HashSet<T>的Contains方法複雜度是O(1

今天我們繼續學習WCF分布式開發步步為贏系列的12節：WCF事務機制（Transaction）和分散式交易編程。眾所周知，應用系統開發過程中，事務是一個重要的概念。它是保證資料與服務可靠性的重要機制。作為面向服務應用的開發平台，WCF也提供了對事物編程模型的支援。.NET 2.0提供的System.Transactions類來開發事務應用程式。同樣WCF也支援事務特性，WCF事務機制是什麼，它與微軟已有的技術如Microsoft 分散式交易協調器 (MSDTC)有何關係？與Enterpise

本節繼續學習WCF分布式開發步步為贏(7):WCF資料契約與序列化.資料契約是WCF應用程式開發中一個重要的概念，毫無疑問實現用戶端與服務端資料契約的傳遞中序列化是非常重要的步驟。那麼序列化是什嗎？為什麼會有序列化機制？或者說它是為瞭解決什麼問題？作用是什嗎？現有的.NET 序列化機制和WCF序列化機制有什麼不同？我們在本節文章裡都會詳細介紹。本節結構：【0】資料契約【1】序列化基本概念【2】.NET

一．建立Web工程建立一個Web網站或者Web應用程式，添加對Castle.ActiveRecord.dll的引用。二．建立需要持久化的業務實體在.NET2.0下，由於引入了泛型，建立業務實體比1.1下簡單了許多，業務實體只需要繼承於泛型的ActiveRecordBase類，其中預設已經實現了一些靜態方法，不需要我們再在業務實體中實現。[ActiveRecord("Employees")]public class Employee : ActiveRecordBase<

伺服器是幹啥子用滴？監聽用戶端，響應用戶端用滴！雖然是世界上最簡陋的伺服器，但是也有幾個注意點：1.因為要一個死迴圈監聽用戶端響應，也就是說無法和使用者進行互動了，所以防止前台假死就要為監聽新起一個線程；2.要把新起的線程td.IsBackground = true;設定為後台線程，這樣的話線程才會隨著應用程式的關閉而關閉，不然的話關了表單，它還在運行；3.跨線程問題，在新的線程裡改變UI會報跨線程改變UI的錯誤，所以要用Invoke;4.在監聽的死迴圈中加入　 Thread.Sleep(1);

批次更新是指在一個事務中更新大批量資料，大量刪除是指在一個事務中刪除大批量資料。以下程式直接通過Hibernate API批次更新CUSTOMERS表中年齡大於零的所有記錄的AGE欄位：tx = session.beginTransaction();Iterator customers=session.find("from Customer c where c.age>0").iterator();while(customers.hasNext()){Customer