我是很新，ADO.NET，和我有點困惑，並通過可用於操縱數據的選項數量感到沮喪。有常規的ADO.NET，LINQ to SQL，Entity Framework。如何決定使用哪種ADO.NET方法？
現在我正在開發一個IRC客戶端，並使用ADO.NET（和SQLite的提供商）來存儲像網絡，服務器，喜歡的頻道設置等
我如何決定使用哪一種？
編輯：另一件我需要做的事情，我想我應該提到的是，爲了編輯和管理它們，「綁定」到GUI的設置。例如，在左側的TreeView和右側的文本框中使用網絡和設置的設置對話框來編輯它們。
首先，Linq-to-SQL僅適用於Microsoft SQL Server--因此，就您的情況而言，該選項將立即顯示在窗口之外。
接下來，我想你確實需要決定你的數據訪問將如何棘手，多麼複雜。
如果你主要處理幾個表格，每個表格都包含幾列，並且你需要讀取和寫入一些信息，那麼你最好使用標準的，直線的ADO.NET（類似於執行SQL查詢的ADO.NET連接和命令對象）。在這種情況下，它是由你來處理所有的「翻譯」關係模型之間（在數據庫中的行和列），以及對象，你在你的應用程序有 - 這是一個有點gruntwork的，有時有點重複編碼的 - 但它的工作原理，它很容易爲簡單的場景，併爲您提供最好的基礎，理解ADO.NET的內部運作（如果你是相當新的吧）。
ADO.NET實體框架和Linq-to-Entities是完全不同的野獸 - 而且更復雜一點。它真正的亮點，當你有非常大的應用，有幾十或數百個表在你的數據庫，在您的應用程序大和可能複雜的業務對象模型，你需要支持所有類型的後端的（SQL服務器，Oracle，Postgres的等。 ）。 EF英孚允許您在一個設計師定義對象之間的關係存儲在數據庫中（其列的「客戶」表）的映射（你的「客戶」類及其性質），並和EF會處理很多的爲表格和你的域對象之間的映射工作煩瑣的工作 - 但它肯定是要學習更多東西。
所以在你的情況下，用一個相當簡單的應用程序，我肯定會建議現在只使用普通的舊ADO.NET，以瞭解繩索並獲得它的工作原理。我不認爲在你的情況下，EF路線是值得的麻煩和學習曲線。
馬克
對於你正在做的輕量級工作，LINQ與SQLite提供者在我看來是非常合適的。
要闡述：
如果你正在做一個非常-數據密集型應用程序，ADO.NET可能是你最好的性能VS可用性。但是，如果您需要執行諸如查詢多個數據源，業務層驗證或審計注入等高級事務，Entity Framework可能是您最好的選擇。
我真的不明白爲什麼你需要ADO的。爲什麼不使用.NET的內置設置持久性框架？這會將設置作爲XML文件自動存儲在每個用戶的基礎上。
由於數據的關係性質。 （網絡有很多服務器，它們有很多通道）除非你認爲這不會是一個問題？ –
這實際上只是關係數據。你可以在你的設置中存儲字典和列表。因此，例如，您可以有一個將網絡映射到服務器列表的字典，並且該字典可以是包含服務器名稱，服務器地址，描述，端口等的類。這一切都非常緊張。 –
LINQ與SQLite的提供者是實體框架。不知道爲什麼你有不同的選項分開...... –