以下是本人對.Net平臺開發實踐的一些點滴總結。這裏的技術規範主要是開發過程的代碼規範、數據庫設計規範、Com和.Net互操作規範；實踐精華是對技術實踐過程中的部分總結。
良好的代碼風格來自於同一的代碼規範。風格良好的代碼不僅具備可讀性和可維護性，同時也給人行雲流水、賞心悅目之快感。
據Microsoft公司統計，基於微軟平臺的開發中，有70-80%的印度工程師在完成同類算法或者模塊時，使用的代碼基本一致；而相同的調查中只有20%的中國工程師們是基本一致的。這說明我們的代碼生產過程亟待規範。
類型、變量、常量、方法等標識符一律採用對應的英文實義；如果涉及到兩個獨立的實義單詞，則中間用下劃線間隔或者單詞首字母大寫（兩種方式都可以）；如果標識符的長度超過了30個字母，則基本上以英文單詞發音的重讀音節取選出三個字母，如Repeater用rpt，Management用mgt。
目前一般有兩種大小寫規則：
Pascal大小寫形式，所有單詞第一個字母大寫，其他字母小寫。
Camel大小寫形式，除了第一個單詞，所有單詞第一個字母大寫，其他字母小寫。
n 類名使用Pascal大小寫形式
public class HelloWorld（或者Hello_World，以下同，不再贅述）
{
...
}
n 方法使用Pascal大小寫形式
public class HelloWorld（）
{
void SayHello(string name)
{
...
}
}
n 變量和方法參數使用Camel 大小寫形式
public class HelloWorld（）
{
int totalCount = 0;
void SayHello(string name)
{
string fullMessage = "Hello " + name;
...
}
}
n 不要使用匈牙利方法來命名變量
以前，多數程序員喜歡把數據類型作爲變量名的前綴而m_作爲成員變量的前綴。例如： string m_sName；int nAge；
然而，這種方式在.NET編碼規範中是不推薦的。所有變量都用Camel 大小寫形式，而不是用數據類型和m_來作前綴。
用name，address，salary等代替nam，addr，sal。
別使用單個字母的變量象i，n，x 等。使用 index，temp等。用於循環迭代的變量例外：
如果變量只用於迭代計數，沒有在循環的其他地方出現，允許用單個字母的變量命名，而不是另外取實義名。
文件名要和類名匹配，例如，對於類HelloWorld，相應的文件名應爲helloworld.cs。
n 縮進用TAB，不用 SPACES。
n 註釋需和代碼對齊。
n 遵循VS2005的自動對齊規則，不要人爲的調整。
n 用一個空行來分開代碼的邏輯分組。
n 在一個類中，各個方法的實現體必須用空行間隔，大括弧“{}”需獨立一行。
n 在每個運算符和括號的前後都空一格。如：
If ( showResult == true )
{
for ( int i = 0; i < 10; i++ )
{
//
}
}
而不是：
if(showResult==true)
{
for(int i= 0;i<10;i++)
{
//
}
}
n 避免使用大文件。如果一個文件裏的代碼超過300～400行，必須考慮將代碼分開到不同類中。
n 避免寫太長的方法。一個典型的方法代碼在1～30行之間。如果一個方法發代碼超過30行，應該考慮將其分解爲不同的方法。
n 方法名需能看出它作什麼。別使用會引起誤解的名字。如果名字一目瞭然，就無需用文檔來解釋方法的功能了。
n 一個方法只完成一個任務。不要把多個任務組合到一個方法中，即使那些任務非常小。
n 使用C# 的特有類型，而不是System命名空間中定義的別名類型。如：
int age;
string name;
object contactInfo;
而不是：
Int16 age;
String name;
Object contactInfo;
n 別在程序中使用固定數值，用常量代替。別用字符串常數，儘量用資源文件。
n 避免使用很多成員變量，聲明局部變量，並傳遞給方法。
n 不要在方法間共享成員變量，如果在幾個方法間共享一個成員變量，那就很難知道是哪個方法在什麼時候修改了它的值。必要時使用enum，別用數字或字符串來指示離散值。
n 別把成員變量聲明爲 public或 protected。都聲明爲private 而使用 public/protected 的Properties。
n 不在代碼中使用具體的路徑和驅動器名，使用相對路徑，並使路徑可編程。永遠別設想你的代碼是在"C:"盤運行。你不會知道，一些用戶在網絡或"Z:"盤運行程序。
n 應用程序啓動時作些“自檢”並確保所需文件和附件在指定的位置。必要時檢查數據庫連接，出現任何問題給用戶一個友好的提示。
n 如果需要的配置文件找不到，應用程序需能自己創建使用默認值。如果在配置文件中發現錯誤值，應用程序要拋出錯誤，給出提示消息告訴用戶正確值。錯誤消息需能幫助用戶解決問題。
n 別每行代碼，每個聲明的變量都做註釋。在需要的地方註釋。
n 可讀性強的代碼需要很少的註釋，如果所有的變量和方法的命名都很有意義，會使代碼可讀性很強並無需太多註釋。行數不多的註釋會使代碼看起來優雅。
n 如果因爲某種原因使用了複雜艱澀的原理，必須爲程序配備良好的文檔和詳細的註釋。
n 對註釋做拼寫檢查，保證語法和標點符號的正確使用。
n 數據表的分類
u 系統表 支撐業務模型的數據表，如流程模型、系統管理相關表。
u 業務表 產品提供的針對業務的通用功能模塊相關表，如通用業務查詢等。
u 用戶表 用戶二次開發使用的與具體業務相關的數據表。
n 數據表的命名
u 所有表格命名一律以字母“T”開頭（Table），並且用實義單詞以下劃線“_”間隔。
u 系統表 系統表前綴爲：TSYS_
u 業務表前綴爲：TBIZ_
u 用戶表由用戶自行定義，但是建議不要與系統表和業務表的命名規則重複。
n 字段的命名
字段的命名規則參照代碼標識符的命名規則，但是注意避開數據庫的保留字。比如不要採用這樣的字段名：index，field，password，id，Oracle，SQL等等。
對於涉及到技術核心的系統表，爲了防止剖析，建議採用類似“F1，F2，F3……Fn”的方式命名。但是不要採用“F0”，因爲這個名稱在某些數據庫中不被允許，比如Interbase。
n 索引是一把雙刃劍，索引將提高查詢的效率，但是卻降低了insert/delete/update 的效率。
n 通常情況下，對數據的編輯頻度和時限要求遠遠低於對數據庫的查詢要求，因此對於記錄很多且頻繁查詢的數據表，必須建立索引。
n 大多數數據庫爲主鍵字段自動創建索引，注意爲外鍵創建索引。
n 不要索引大字段，這樣作會讓索引佔用太多的存儲空間。
n 儘量不要索引頻繁編輯的小型表。
n identify字段不要作爲表的主鍵與其它表關聯，這將會影響到該表的數據遷移。如果考慮支持多數據庫，建議主鍵採用程序生成的唯一值。
n 如果一個大型表需要頻繁的做insert/delete/update操作，同時也需要做高併發量的查詢，那麼建議根據數據的訪問頻度對錶作拆分，而後建立索引。
數據庫廠商爲了凸現自身的優勢，都提供了豐富且個性化的過程與函數。
爲了提升產品的伸縮性和數據無關性，請不要使用與特定數據庫相關的過程與函數，也不推薦採用Store Procedure，建議使用應用服務器的中間層業務對象。
n 儘量避免使用Blob，如果一定要用，請不要索引blob，並且不要定義多個blob。
n 不要使用日期字段，改用字符串char(19)替代，如：2008-12-09 12:22:08。
n 對於確定長度的串，請固定字段類型的長度，如char（80），不要採用varchar。
n 對於值類型字段，請使用對應的數據庫值類型，而不要用字符串。
.NET 技術已經成爲微軟平臺的主流，但是在Win32時代開發了很多COM、DCOM組件，由於在開發COM組件時投入了大量的人力、財力，如何在.NET環境下重用這些COM組件就顯得更有意義。
.NET支持運行時通過COM、COM＋、本地WinAPI調用與未託管代碼的雙向互操作性，要實現互操作性，必須首先引入.NET Framework的 System.Runtime.InteropServices命名空間。
C#的語法爲：
using System.Runtime.InteropServices;
（1）.NET訪問API
.NET允許C＃訪問未託管的DLL的函數。如要調用Windows User32.dll的MessageBox函數：
int MessageBox(HWND hwnd,LPCTSTR lpText, LPCTSTR lpCaption,UINT uType)
可以聲明一個具有DLLImport屬性的static extern方法：
using System.Runtime.InteropServices；
[DllImport(“user32.dll”)]
static ertern int MessageBox(int hwnd,string text,string caption,int type);
然後在代碼裏面直接調用就可以了。這裏要注意在調用返回字符串的API中使用StringBuilder對象。
（2）.NET訪問COM組件
從.NET調用COM組件比較容易，只要使用tlbimp.exe產生COM的裝配形式的WarpClass，然後在.NET項目中調用即可。
注意COM的類型信息通過Type Library文件描述，.NET裝配件是自描述的。Tlbimp的作用是從COM組件及其類型信息中產生自描述的裝配件。
1．編寫Com組件
編譯生成一個ComAccount.dll。
2. 產生.NET可訪問的包裝類（assembly），使用TlbImp.exe產生.NET裝配件。
TlbImp /out：NetAccount.dll ComAccount.dll
3．在.NET代碼中訪問
.NET代碼只需引用NetAccount.dll,就可以像訪問.NET的裝配件一樣訪問COM組件。
n 在應用程序級（線程級）錯誤處理器中處理所有的一般異常。遇到“意外的一般性錯誤”時，此刻錯誤處理器應該捕捉異常，給用戶提示消息，在應用程序關閉或用戶選擇“忽略並繼續”之前記錄錯誤信息。
n 不必每個方法都用try-catch，當特定的異常可能發生時才使用。比如，當寫文件時，處理異常FileIOException。
n 別寫太大的 try-catch 模塊。如果需要，爲每個執行的任務編寫單獨的 try-catch 模塊。這將有助於找出哪一段代碼產生異常，並給用戶發出特定的錯誤消息。
n 如果應用程序需要，可以編寫自己的異常類。自定義異常不應從基類SystemException派生，而要繼承於IApplicationException。
n 在開發階段，不必在所有方法中捕捉一般異常。刻意的放縱異常，將幫助在開發週期發現大多數的錯誤。
n 不要捕捉了異常卻什麼也不做，看起來系統似乎在正常運行。如果這樣隱藏了一個異常，將永遠不知道異常到底是否發生，爲什麼發生。
n 發生異常時，給出友好的消息給用戶。但要精確記錄錯誤的所有可能細節，包括髮生的時間，和相關方法，類名等。
n 永遠別用像“應用程序出錯”，“發現一個錯誤”等錯誤提示消息，而應給出類似“更新數據庫失敗，請確保登陸id和密碼正確。”之類的具體消息。
n 顯示錯誤消息時，還應提示用戶如何解決問題。如：“更新數據庫失敗，請確保登陸id和密碼正確。”，而不是僅僅說“更新數據庫失敗”。
n 顯示給用戶的消息要簡短而友好。但要把所有可能的信息都記錄下來，以助診斷問題。
推薦如下異常處理模式：
void ReadFromFile ( string fileName )
{
try
{
// 讀文件.
}
catch (FileIOException ex)
{
// 記載異常日誌
// 重拋具有針對性的異常信息
throw;
}
}
不推薦如下的異常處理模式：
void ReadFromFile ( string fileName )
{
try
{
// 讀文件
}
catch (Exception ex)
{
// 捕捉一般異常將讓我們永遠不知道到底是文件錯誤還是其他錯誤
// 隱藏異常將我們永遠不知道有錯誤發生。
return "";
}
}
.Net平臺的垃圾回收機制，可以自動的dispose不再引用的對象實例，所以很多開發人員並不主動釋放申請的對象資源。事實上，在對象的生命週期結束之前是不會被釋放的。
但是，很多時候當對象處於生命週期之內時，我們不再使用它，以便釋放資源提升系統效率。因此，主動釋放申請的資源顯得很有必要。
永遠不要把力所能及的事情交給操作系統，及時釋放不再使用的資源是一個好習慣。
數據庫訪問永遠是系統的瓶頸，選擇高效、穩健的數據庫訪問模式是產品性能的基礎保證。
n 永遠不要假設你的應用系統構建與某個數據庫之上，因此必須有統一的、透明的數據庫訪問機制。
n 採用ADO.Net訪問數據庫 基於效率和穩定性的考量，採用微軟平臺原生的數據庫訪問模式ADO.Net。使用ADO.Net可以通過OLEDB和ODBC兩種模式訪問數據庫，我們建議使用數據庫廠商提供的OLEDB模式，這種模式繞過了ODBC，使得數據庫的遊標性能大大提升，效率更佳。
n 不使用第三方的數據持久層 使用類似於Nhibernate之類的第三方數據持久層工具雖然可以提高開發的效率，但是卻降低了系統的性能。性能對於產品而言，遠遠比開發效率重要的多。況且基於VS2005的開發，效率不是問題。
n 使用自主產權的數據對象 直接採用ADO.Net封裝最底層的數據訪問方法：插入、刪除和更新，以及事務管理等；客戶端和服務器端採用相同的數據訪問機制，並設立連接緩衝池提升數據訪問效率。
對於多層分佈式應用而言，數據庫事務呈現出“遠程、分佈”的特色，導致事務難以管理。
對於Ado.Net而言，事務綁定了數據庫連接，因此必須在數據訪問對象中對每一個數據庫連接管理各自的事務或嵌套事務。如果要訪問數據庫，服務器上的數據訪問對象將自動分配一個特定的連接，根據該連接ID執行數據操作；無論該事務分佈於多少個遠程客戶端進程，服務器數據對象只需要鎖定連接ID即可輕鬆進行事務管理。
智能客戶端是易於部署和管理的客戶端應用程序，它綜合了瘦客戶端和胖客戶端的優點，通過統籌使用本地資源和到分佈式數據資源的智能連接，提供快速響應的和豐富的交互式體驗。
智能客戶端分爲Windows Form，Office Client，Mobile Client三種類型，具有如下特點：
n 利用本地資源
n 利用網絡資源
n 支持偶爾連接的用戶
n 提供智能安裝和更新
n 提供客戶端設備靈活性
.NET 框架基類庫內嵌了支持智能客戶端的豐富程序集，通過使用公共語言運行庫 (CLR)，可以利用任何受到 .NET 支持的語言來開發智能客戶端。
智能客戶端是瘦客戶段的強大替代品，也是微軟推薦的客戶端模式。儘量使用智能客戶端而不要使用瀏覽器。如果可以，請把你的客戶端系統構建在Office平臺上，如Outlook。