快捷導(dǎo)航

.Net平臺(tái)開發(fā)實(shí)踐的一些點(diǎn)滴總結(jié)(技術(shù)規(guī)范與實(shí)踐精華)第2/2頁

更新時(shí)間：2010年04月06日 15:00:41 作者：

以下是本人對(duì).Net平臺(tái)開發(fā)實(shí)踐的一些點(diǎn)滴總結(jié)。這里的技術(shù)規(guī)范主要是開發(fā)過程的代碼規(guī)范、數(shù)據(jù)庫(kù)設(shè)計(jì)規(guī)范、Com和.Net互操作規(guī)范；實(shí)踐精華是對(duì)技術(shù)實(shí)踐過程中的部分總結(jié)。

過程與函數(shù)

數(shù)據(jù)庫(kù)廠商為了凸現(xiàn)自身的優(yōu)勢(shì)，都提供了豐富且個(gè)性化的過程與函數(shù)。

為了提升產(chǎn)品的伸縮性和數(shù)據(jù)無關(guān)性，請(qǐng)不要使用與特定數(shù)據(jù)庫(kù)相關(guān)的過程與函數(shù)，也不推薦采用Store Procedure，建議使用應(yīng)用服務(wù)器的中間層業(yè)務(wù)對(duì)象。

字段/域的定義

盡量避免使用Blob，如果一定要用，請(qǐng)不要索引blob，并且不要定義多個(gè)blob。

不要使用日期字段，改用字符串char(19)替代，如：2008-12-09 12:22:08。

對(duì)于確定長(zhǎng)度的串，請(qǐng)固定字段類型的長(zhǎng)度，如char（80），不要采用varchar。

對(duì)于值類型字段，請(qǐng)使用對(duì)應(yīng)的數(shù)據(jù)庫(kù)值類型，而不要用字符串。

三、Com和.Net互操作規(guī)范

.NET 技術(shù)已經(jīng)成為微軟平臺(tái)的主流，但是在Win32時(shí)代開發(fā)了很多COM、DCOM組件，由于在開發(fā)COM組件時(shí)投入了大量的人力、財(cái)力，如何在.NET環(huán)境下重用這些COM組件就顯得更有意義。

.NET支持運(yùn)行時(shí)通過COM、COM＋、本地WinAPI調(diào)用與未托管代碼的雙向互操作性，要實(shí)現(xiàn)互操作性，必須首先引入.NET Framework的 System.Runtime.InteropServices命名空間。

C#的語法為：

using System.Runtime.InteropServices;

1) .NET訪問API

.NET允許C＃訪問未托管的DLL的函數(shù)。如要調(diào)用Windows User32.dll的MessageBox函數(shù)：

int MessageBox(HWND hwnd,LPCTSTR lpText, LPCTSTR lpCaption,UINT uType)

可以聲明一個(gè)具有DLLImport屬性的static extern方法：

using System.Runtime.InteropServices；

[DllImport(“user32.dll”)]

static ertern int MessageBox(int hwnd,string text,string caption,int type);

然后在代碼里面直接調(diào)用就可以了。這里要注意在調(diào)用返回字符串的API中使用StringBuilder對(duì)象。

2) .NET訪問COM組件

從.NET調(diào)用COM組件比較容易，只要使用tlbimp.exe產(chǎn)生COM的裝配形式的WarpClass，然后在.NET項(xiàng)目中調(diào)用即可。

注意COM的類型信息通過Type Library文件描述，.NET裝配件是自描述的。Tlbimp的作用是從COM組件及其類型信息中產(chǎn)生自描述的裝配件。

1．編寫Com組件

編譯生成一個(gè)ComAccount.dll。

2. 產(chǎn)生.NET可訪問的包裝類（assembly），使用TlbImp.exe產(chǎn)生.NET裝配件。

TlbImp /out：NetAccount.dll ComAccount.dll

3．在.NET代碼中訪問

.NET代碼只需引用NetAccount.dll,就可以像訪問.NET的裝配件一樣訪問COM組件。

四、異常處理

異常處理的原則

在應(yīng)用程序級(jí)（線程級(jí)）錯(cuò)誤處理器中處理所有的一般異常。遇到“意外的一般性錯(cuò)誤”時(shí)，此刻錯(cuò)誤處理器應(yīng)該捕捉異常，給用戶提示消息，在應(yīng)用程序關(guān)閉或用戶選擇“忽略并繼續(xù)”之前記錄錯(cuò)誤信息。

不必每個(gè)方法都用try-catch，當(dāng)特定的異?？赡馨l(fā)生時(shí)才使用。比如，當(dāng)寫文件時(shí)，處理異常FileIOException。

別寫太大的 try-catch 模塊。如果需要，為每個(gè)執(zhí)行的任務(wù)編寫單獨(dú)的 try-catch 模塊。這將有助于找出哪一段代碼產(chǎn)生異常，并給用戶發(fā)出特定的錯(cuò)誤消息。

如果應(yīng)用程序需要，可以編寫自己的異常類。自定義異常不應(yīng)從基類SystemException派生，而要繼承于IApplicationException。

在開發(fā)階段，不必在所有方法中捕捉一般異常?？桃獾姆趴v異常，將幫助在開發(fā)周期發(fā)現(xiàn)大多數(shù)的錯(cuò)誤。

異常處理的提示

不要捕捉了異常卻什么也不做，看起來系統(tǒng)似乎在正常運(yùn)行。如果這樣隱藏了一個(gè)異常，將永遠(yuǎn)不知道異常到底是否發(fā)生，為什么發(fā)生。

發(fā)生異常時(shí)，給出友好的消息給用戶。但要精確記錄錯(cuò)誤的所有可能細(xì)節(jié)，包括發(fā)生的時(shí)間，和相關(guān)方法，類名等。

永遠(yuǎn)別用像“應(yīng)用程序出錯(cuò)”，“發(fā)現(xiàn)一個(gè)錯(cuò)誤”等錯(cuò)誤提示消息，而應(yīng)給出類似“更新數(shù)據(jù)庫(kù)失敗，請(qǐng)確保登陸id和密碼正確?！敝惖木唧w消息。

顯示錯(cuò)誤消息時(shí)，還應(yīng)提示用戶如何解決問題。如：“更新數(shù)據(jù)庫(kù)失敗，請(qǐng)確保登陸id和密碼正確?！保皇莾H僅說“更新數(shù)據(jù)庫(kù)失敗”。

顯示給用戶的消息要簡(jiǎn)短而友好。但要把所有可能的信息都記錄下來，以助診斷問題。

異常處理的代碼實(shí)例

推薦如下異常處理模式：

void ReadFromFile ( string fileName )
{
try
{
// 讀文件.
}
catch (FileIOException ex)
{
// 記載異常日志
// 重拋具有針對(duì)性的異常信息
throw;
}
}

不推薦如下的異常處理模式：

void ReadFromFile ( string fileName )
{
try
{
// 讀文件
}

catch (Exception ex)
{
// 捕捉一般異常將讓我們永遠(yuǎn)不知道到底是文件錯(cuò)誤還是其他錯(cuò)誤
// 隱藏異常將我們永遠(yuǎn)不知道有錯(cuò)誤發(fā)生。
return "";
}
}

五、對(duì)象實(shí)例的申請(qǐng)與釋放

.Net平臺(tái)的垃圾回收機(jī)制，可以自動(dòng)的dispose不再引用的對(duì)象實(shí)例，所以很多開發(fā)人員并不主動(dòng)釋放申請(qǐng)的對(duì)象資源。事實(shí)上，在對(duì)象的生命周期結(jié)束之前是不會(huì)被釋放的。

但是，很多時(shí)候當(dāng)對(duì)象處于生命周期之內(nèi)時(shí)，我們不再使用它，以便釋放資源提升系統(tǒng)效率。因此，主動(dòng)釋放申請(qǐng)的資源顯得很有必要。

永遠(yuǎn)不要把力所能及的事情交給操作系統(tǒng)，及時(shí)釋放不再使用的資源是一個(gè)好習(xí)慣。

六、數(shù)據(jù)庫(kù)訪問

數(shù)據(jù)庫(kù)訪問永遠(yuǎn)是系統(tǒng)的瓶頸，選擇高效、穩(wěn)健的數(shù)據(jù)庫(kù)訪問模式是產(chǎn)品性能的基礎(chǔ)保證。

永遠(yuǎn)不要假設(shè)你的應(yīng)用系統(tǒng)構(gòu)建與某個(gè)數(shù)據(jù)庫(kù)之上，因此必須有統(tǒng)一的、透明的數(shù)據(jù)庫(kù)訪問機(jī)制。

采用ADO.Net訪問數(shù)據(jù)庫(kù)

基于效率和穩(wěn)定性的考量，采用微軟平臺(tái)原生的數(shù)據(jù)庫(kù)訪問模式ADO.Net。使用ADO.Net可以通過OLEDB和ODBC兩種模式訪問數(shù)據(jù)庫(kù)，我們建議使用數(shù)據(jù)庫(kù)廠商提供的OLEDB模式，這種模式繞過了ODBC，使得數(shù)據(jù)庫(kù)的游標(biāo)性能大大提升，效率更佳。

不使用第三方的數(shù)據(jù)持久層使用類似于Nhibernate之類的第三方數(shù)據(jù)持久層工具雖然可以提高開發(fā)的效率，但是卻降低了系統(tǒng)的性能和彈性。性能對(duì)于產(chǎn)品而言，遠(yuǎn)遠(yuǎn)比開發(fā)效率重要的多，況且基于VS2005的開發(fā)，效率不是問題。請(qǐng)記?。旱谌降墓ぞ哂肋h(yuǎn)不能成為你的產(chǎn)品核心技術(shù)；數(shù)據(jù)訪問機(jī)制是系統(tǒng)的效率瓶頸，對(duì)

使用自主產(chǎn)權(quán)的數(shù)據(jù)對(duì)象

直接采用ADO.Net封裝最底層的數(shù)據(jù)訪問方法：插入、刪除和更新，以及事務(wù)管理等；客戶端和服務(wù)器端采用相同的數(shù)據(jù)訪問機(jī)制，并設(shè)立連接緩沖池提升數(shù)據(jù)訪問效率。

七、分布式事務(wù)管理

對(duì)于多層分布式應(yīng)用而言，數(shù)據(jù)庫(kù)事務(wù)呈現(xiàn)出“遠(yuǎn)程、分布”的特色，導(dǎo)致事務(wù)難以管理。

對(duì)于Ado.Net而言，事務(wù)綁定了數(shù)據(jù)庫(kù)連接，因此必須在數(shù)據(jù)訪問對(duì)象中對(duì)每一個(gè)數(shù)據(jù)庫(kù)連接管理各自的事務(wù)或嵌套事務(wù)。如果要訪問數(shù)據(jù)庫(kù)，服務(wù)器上的數(shù)據(jù)訪問對(duì)象將自動(dòng)分配一個(gè)特定的連接，根據(jù)該連接ID執(zhí)行數(shù)據(jù)操作；無論該事務(wù)分布于多少個(gè)遠(yuǎn)程客戶端進(jìn)程，服務(wù)器數(shù)據(jù)對(duì)象只需要鎖定連接ID即可輕松進(jìn)行事務(wù)管理。

八、智能客戶端

智能客戶端是易于部署和管理的客戶端應(yīng)用程序，它綜合了瘦客戶端和胖客戶端的優(yōu)點(diǎn)，通過統(tǒng)籌使用本地資源和到分布式數(shù)據(jù)資源的智能連接，提供快速響應(yīng)的和豐富的交互式體驗(yàn)。

智能客戶端分為Windows Form，Office Client，Mobile Client三種類型，具有如下特點(diǎn)：

利用本地資源

利用網(wǎng)絡(luò)資源

支持偶爾連接的用戶

提供智能安裝和更新

提供客戶端設(shè)備靈活性

.NET 框架基類庫(kù)內(nèi)嵌了支持智能客戶端的豐富程序集，通過使用公共語言運(yùn)行庫(kù) (CLR)，可以利用任何受到 .NET 支持的語言來開發(fā)智能客戶端。

智能客戶端是瘦客戶段的強(qiáng)大替代品，也是微軟推薦的客戶端模式。盡量使用智能客戶端而不要使用瀏覽器。如果可以，請(qǐng)把你的客戶端系統(tǒng)構(gòu)建在Office平臺(tái)上，如Outlook。

上一頁 12閱讀全文