我是一個非常新的Java翻新C＃。當我在接下來的幾周內發佈了一堆DML代碼時，我希望能夠避免麻煩。爲什麼不是DbConnection而不是SqlConnection或OracleConnection？
我習慣於使用JDBC的抽象類，如連接，語句等的想法。 C＃在System.Data.Common命名空間中提供了類似的抽象類，如DbConnection，DbCommand等等。
但是，我見過的絕大多數例子 - 無論是MS文檔還是其他書籍 - 都使用具體類：SqlConnection，OracleCommand等。這種具體性甚至在mySQL文檔中出現。
這方面的最佳做法是什麼？是否有強烈的理由選擇具體的表特定於服務器而不是抽象類來達到這個目的？ （當然，我意識到將抽象描述向下傾斜的危險）。
抽象類不是框架的第一個版本的一部分，它們在2.0版中引入。在此之前寫了很多例子，或者是基於之前編寫的例子。
使用混凝土或抽象類主要是品味的問題。編寫可用於任何數據庫的代碼是一個不錯的主意，但我的經驗是，您不會經常更換數據庫系統，如果您執行的操作有太多變化，您需要做的事情無關緊要如果你使用抽象類或不。
大多數特定於數據庫的ADO.NET類都有額外的重載和/或特定於該數據庫驅動程序的方法和屬性。
使用像SqlConnection和OracleConnection這樣的具體類可以更輕鬆地訪問驅動程序特定的功能。
通常，當您知道您的公司或您正在使用的數據庫時，您的目標是該特定的數據庫類型。如果你知道它的Oracle，那麼你使用Oracle相關的類，如果它的SQLClient，那麼你使用SqlClient等等。現在
，如果您不確定哪個類型是的話，你會去爲一個參考通用/通用格式，這樣就可以不必擔心數據庫類型實現自己的目標。反過來，寫一堆條件語句來檢查數據庫的類型，然後按照它執行操作。
常見的情況，幫助你理解是：如果你正在編寫的代碼，從而使最終用戶可以更改配置文件，並輸入一個連接字符串連接到數據庫，提供你會被利用？這是DbFactory及其相關類派上用場的地方，不用編寫代碼塊，而是使用泛型類（我猜）來處理所有事情。
請記住，如果確實針對某個特定的提供者，您將會獲得更好的性能（因爲DbFactory在處理它之前必須在內部解析您的提供者），但是如果您不確定最終用戶提供者，既大又不高效。
來到你的另一個問題：抽象或具體。它取決於你，再次，它的情景基礎。抽象的優點在於，你可以強制/阻止客戶端遵守規則（比如接口），以及你可以概括事物以及利用類型轉換（類似於具體類）來訪問子類方法來執行某些操作（檢查關於這個話題，如果可以的話。使用運行時多態，您可以使用一個對象並調用一個方法，該方法在子類別爲此父類的不同類中具有不同的實現，您無需擔心這些類 - 例如計算興趣可能是簡單興趣和複合興趣一個銀行，這是由各自的班級計算 - 但你不關心它，因爲你只是說 - GetInterest（）和繁榮！）。
在一個你不知道最終用戶正在使用的數據庫類型並且不知道連接字符串的情況下，你可能想強制最終用戶實現你的類，執行抽象方法來初始化連接字符串，然後執行必要的操作以提供輸出。
希望它有幫助。