過程與函數(shù)

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

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

字段/域的定義

盡量避免使用Blob，如果一定要用，請不要索引blob，并且不要定義多個blob。

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

對于確定長度的串，請固定字段類型的長度，如char（80），不要采用varchar。

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

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

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

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

C#的語法為：

1) .NET訪問API

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

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

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

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

2) .NET訪問COM組件

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

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

1．編寫Com組件

編譯生成一個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)用程序級（線程級）錯誤處理器中處理所有的一般異常。遇到“意外的一般性錯誤”時，此刻錯誤處理器應(yīng)該捕捉異常，給用戶提示消息，在應(yīng)用程序關(guān)閉或用戶選擇“忽略并繼續(xù)”之前記錄錯誤信息。

不必每個方法都用try-catch，當特定的異常可能發(fā)生時才使用。比如，當寫文件時，處理異常FileIOException。

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

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

在開發(fā)階段，不必在所有方法中捕捉一般異常。刻意的放縱異常，將幫助在開發(fā)周期發(fā)現(xiàn)大多數(shù)的錯誤。

異常處理的提示

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

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

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

顯示錯誤消息時，還應(yīng)提示用戶如何解決問題。如：“更新數(shù)據(jù)庫失敗，請確保登陸id和密碼正確?！?，而不是僅僅說“更新數(shù)據(jù)庫失敗”。

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

異常處理的代碼實例

推薦如下異常處理模式：

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

五、對象實例的申請與釋放

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

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

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

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

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

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

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

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

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

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

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

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

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

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

八、智能客戶端

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

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

利用本地資源

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

支持偶爾連接的用戶

提供智能安裝和更新

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

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

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

最新評論