1
使用說明
nframework設計之初就從編碼人員的角度來考慮，最終的目的也是為編碼人員服務,因此，**的簡潔性與易用性成為嚴格的設計標準。nframework充分遵循了「介面隔離原則」，使使用者**不必再依賴於介面，這樣您從ide環境就可以快速的定位到具體的方法體，避免了「轉到定義」帶來的煩惱。
nframework建議使用者使用三層架構，即表現層、業務邏輯層、資料訪問層。當然如何分層以及各種分層方式的優缺點這裡不再討論，下面將只說明基於三層架構的應用程式使用nframework的具體方法。
1.1
持久化實體類編碼說明
首先，實體類需要從baseentity基類繼承，baseentity類是框架的重要類之一。利用baseentity類中提供的方法可以方便的獲取實體與資料表的影射關係，比如說對映的表名、某個屬性所對應的欄位名等等。不過，baseentity最重要以及最常用的功能則是實體與datatable之間的轉換。只需呼叫乙個方法就可以將實體轉換成datatable，或者從datatable轉換成實體，而這一切不需要再編寫額外的其它**，從而大大減少了編碼的工作量。實體類詳細**參考如下：
//////
使用者實體類，從baseentity類繼承
///ormapingattribute
類用於標識實體與資料表之間的對映關係
///[serializable]
[ormaping(tablename="t_system_user")] //
public
class userentity : baseentity
set }
//////
使用者姓名
///[ormaping(fieldname="user_name",ispk=false,isselected=true,isinserted=true,isupdated=true)] //
public
string username
set }
}通過以上的設定，我們就可以使用如下方法方便的實現實體與datatable之間的轉換。舉例來說：
l將實體轉換成datatable
userentity user = new userentity();
datatable dt = user.convertto(); //
乙個方法就可以轉換了
l將datatable轉換成實體
datatable dt = new datatable();
userentity user = new userentity();
user.convertfrom(dt); //
乙個方法就可以轉換了，也可以使用user.parse(dt)方法
這裡要說明的是baseentity類提供了兩個方法從datatable轉換成實體，即convertfrom和parse。這兩個方法都可以實現轉換的功能，但它們之間有什麼區別呢？
我們知道，利用sql語句返回查詢結果時通常是乙個datatable形式，而datatable中的列名是根據sql語句中的查詢列名來定義的，因此這就產生了datatable中的列如何與實體屬性值匹配的問題。convertfrom方法通過獲取實體屬性對映的欄位名，進而在datatable中查詢同名的列，一旦找到同名列，則會使用此列值作為實體屬性值的資料來源。parse方法和convertfrom相同，只不過parse方法使用實體屬性名的字串形式在datatable中查詢，然後再進行匹配。
另外要說明的就是convertto方法，在使用這個方法將實體轉換成datatable時，會使用實體屬性名稱的字串形式來建立datatable列，這樣在將datatable繫結到datagrid時就可以直接使用屬性名稱了，而不用再關心資料庫中的表結構，即使用表的欄位名改變了也只需要改動實體屬性名的對映值就可以了，對現有**無任何影響，這充分體現了orm的思想，因此convertto方法是非常重要方法，儘管它會帶來一些效能上的開銷，但在遮蔽資料庫方面卻有著非常重要的作用。
1.2
業務邏輯類編碼說明
業務層通常是系統的核心層，使用者所有的業務邏輯均在於此，因此保證使用者業務的完整性是非常重要的。以基於資料訪問的應用程式中，我們通常使用事務來實現業務資料完整性。nframework對業務層的支援主要體現的事務的處理方面，業務層**可以從transaction類繼承，以實現自動事務，或者從transactionscope類繼承以實現分布式事務。無論從哪乙個基類繼承，其實現**都是非常簡單的。下面給出實際的示例**：
l基於連線事務的使用方法示例：
////// 新增使用者的業務邏輯類，從transaction類繼承
///public
class userbll : transaction
catch (exception ex)
return user.userid; }
} l基於分布式事務的使用方法示例：
////// 新增使用者的業務邏輯類，從transactionscope類繼承。此功能需要com+的支援
///public
class userbll : transactionscope
catch (exception ex)
return user.userid; }
}1.3
資料訪問類編碼說明
資料訪問層處於nframework的最底層，是實現與實際的資料庫打交道的地方。nframework對資料訪問層做了限制，即強制其繼承access類，以使用繼承的dbutil屬性實現對資料庫的訪問。另外access類本身提供了相當多的資料訪問方法，使用者完全可用access類的方法實現對資料庫的訪問，而不需要再寫麻煩的資料訪問方法。示例**如下：
//////
資料訪問類，必須繼承access類
///internal
class userdal : access
} 1.4
特殊情況的處理
以上列舉了大多數情況下的資料訪問方法的示例，下面將說明一些特殊情況的處理。
1.4.1
不使用事務進行資料訪問
如果不想使用事務，則不需要使用業務層（bll）中的begintransaction方法，直接使用資料訪問層（dal）層中的dbutil物件即可。nframework框架會自動開啟到資料庫的連線，並且在執行完之後，自動關閉連線。通常建議對新增、修改、刪除等需要更改資料的方法使用事務，而對查詢等獲取資料的方法不強制要求使用事務，但通過使用事務可以保證你寫的業務邏輯**可以被別人「放心」的使用，而不會出現資料不同步的問題。
1.4.2
訪問不同資料庫的處理
nframework框架預設的資料庫連線只有乙個，即在web.config中配置的資料庫連線。因此，如果想操作其它的資料庫，則需要使用access類的getdbutil方法來獲取資料訪問物件。getdbutil方法有兩個引數，分別是資料庫型別和資料庫連線字串，並且返回乙個idbutil介面用於實現對資料庫的抽象訪問。需要注意的是，getdbutil方法並沒有提供事務的處理功能，其實際上只是根據資料庫連線字串開啟乙個連線，並且使用完成之後自動關閉連線。因此，如果對於這種情況也需要使用事務的話，請使用分布式事務。
1.4.3
分布式事務的處理
對事務的處理，我們有三種選擇：
一、基於資料庫級別的事務，通常是在存貯過程中顯示的定義事務，但這種方式的缺點是事務控制的範圍過於狹窄，並且最重要的是很容易將業務邏輯耦合到sql語句的級別，這不但增加編碼的工作量，而且會對系統的架構產生不良影響，同時也不利於系統的公升級與維護，但其優點也很明顯，即其事務控制的效率是最高的。
二、基於ado.net connection級別的事務，這種方式的事務解決了sql語句耦合的問題，使使用者**可以專注於業務邏輯的處理，同時ado.net的事務使用簡單、方便，因此多數應用程式都是採用這種方式來處理事務，但其缺點是無法處理不同資料庫間的事務，一旦應用程式有這樣的需求，則ado.net就顯得無能為力了。並且由於其做事務控制時需要與資料庫之間有乙個往返的通訊過程，所以其效率上要差於在資料庫級別的事務。
三、基於com+的分布式事務，com+提供了自動事務處理的功能，這為我們的程式提供了很大方便，實現分布式事務變得很簡單。nframework框架提供了用於分布式事務的基類transactionscope，使用者**只要從這個基類繼承就可利用com+實現分布式事務。不過其相對麻煩的是，必須將程式集部署到com+環境中，這對於系統的安裝部署方面顯得有些繁瑣。
C 開源的AOP框架
aop面向切面程式設計 aspect oriented programming 是通過預編譯方式和執行期動態 實現程式功能的統一維護的一種技術。spring框架用的核心技術就是aop，是函式式程式設計的一種衍生范型。利用aop的好處www.cppcns.com就是可以對業務邏輯進行隔離，降低耦合度，...
乙個輕量級AOP的實現（開源）
事先宣告，本專案參考aop in c 和園內大神張逸的文章，思路神馬的都不是自己的！為了讓專案的 看起來更乾淨，需要乙個aop！於是就實現了乙個非常簡單的，非常輕量級，有多輕量級呢？實現的aop叫做earthworm 蚯蚓，為什麼叫這個？因為它小，它會疏通！專案的本意也是這樣，所以就叫這個！命名空間...
AOP解密 深入再造AOP
在上篇部落格中，大家和我一起研究了aop的基本實現，但是，也給大家遺留了很多問題，在這篇部落格，咱們一起研究如何針對這些問題進行持續的優化，看看在咱們的手裡，aop會成長為乙個什麼樣的東西！看看上篇部落格中，咱們一起實現的aop類圖 咱們看看在cglib類裡的問題 public class cgli...