使用ADO.NET實體框架編寫「查詢」的大拇指規則

Question

我目前正在研究中型Web應用程序的原型，並且我認爲這也很適合實驗實體框架。問題在於應用程序的主要部分不是數據層和邏輯，所以我沒有太多時間去玩Entity Framework。另一方面，數據庫模式非常簡單。

我面臨的問題之一是我找不到一種「寫查詢」的一致方法。據我所知，有四個 「接口」 作業：

• LINQ到實體
• LINQ使用LINQ擴展方法
• 實體SQL
• 查詢生成器

實體

好吧，前兩個基本上是一樣的，但只用一個維護和一致性是很好的。

我很困惑的事實，他們都沒有完成，最普遍。我經常發現自己陷入了困境，並且使用了其中幾個看起來醜陋的外觀組合。我的猜測是Entity SQL是最普遍的一種，但使用字符串編寫查詢感覺就像退後一步。我正在試驗類似Entity Framework的主要原因是我喜歡編譯時檢查。

其他一些隨筆/問題：

• 我也經常使用ObjectQuery.Include（）方法，但同樣需要一個字符串。這是唯一的方法嗎？
• 何時使用ObjectQuery.Execute（）（與ToList（））？它是否真的執行查詢？
• 應儘快執行查詢（例如使用ToList（）），還是應該不在乎讓第一枚枚舉的執行保持原樣？
• ObjectQuery.Skip（）和ObjectQuery.Take（）僅作爲擴展方法使用嗎？有沒有更好的方法來做分頁？這是2009年，幾乎每個Web應用程序都處理分頁。

總體來說，我理解實現一個ORM時有很多困難，常常一個人妥協。另一方面，直接訪問數據庫（例如ADO.NET）非常簡單明瞭，界面清晰（表格結果，數據讀取器），所以所有代碼 - 無論是誰寫的 - 都是一致的。每當編寫數據庫查詢時，我都不想面對太多的選擇。這太乏味了，很多不同的開發人員會想出不同的方法。

你的經驗法則是什麼？

Answer 1

我儘可能地使用LINQ-to-Entities。我也嘗試將其形式化爲lambda表單，而不是擴展的SQL樣式語法。我必須承認，爲了加快我們對應用程序的編碼（例如，Master-> Child表可能需要手動加載），執行關係和效率方面存在問題，但總而言之，EF是一個很好的產品。

我確實使用EF的.Include（）方法進行延遲加載，正如您所說，它確實需要字符串輸入。我發現沒有問題，除了識別要使用的字符串相對簡單。我猜如果你熱衷於這種關係的編譯時檢查，一個類似於：Parent的模型。GetChildren（）可能更合適。

雖然我的應用程序確實需要執行一些「動態」查詢。我有兩種方法來解決這個問題：

a）我創建了一箇中介對象，例如。 ClientSearchMediator，它「知道」如何通過名稱搜索客戶端等。然後，我可以通過SearchHandler.Search（ISearchMediator [] mediators）調用（例如）。這可以用來定位特定的數據結構並使用LINQ-to-Entities相應地對結果進行排序。 b）爲了更寬鬆的體驗，可能由於用戶設計自己的查詢（使用我們的應用程序提供的高級工具），eSQL非常適合此目的。它可以製成注射安全的。

Answer 2

我沒有足夠的知識來解決所有這些問題，但我至少會採取一些措施。

我不知道你爲什麼認爲ADO.NET比實體框架更一致。有很多不同的方法來使用ADO.NET，並且我已經看到了單個代碼庫中的不一致。

實體框架目前是1.0版本，它遭受了許多1.0類型的問題（不完整的&不一致的API，缺少的功能等）。

關於包含，我假設你指的是急切的加載。多人（微軟以外的人）已經開發出了獲得「類型安全」的解決方案（嘗試搜索類似於Entity Framework ObjectQueryExtension Include）。這就是說，包含比任何東西都更重要。您不能強制加載，並且必須始終記住調用IsLoaded（）方法來查看您的請求是否已完成。據我所知，「包含」方式在下一個實體框架版本（4.0 - 與VS 2010一起發佈）中完全沒有改變。

就一旦建立Linq查詢與最後一個可能的時刻執行Linq查詢，該決定是情境。就個人而言，我可能會盡快執行它，除非有一個令人信服的理由，但我可以看到其他人走向相反的方向。

市場上有更成熟的ORM，實體框架不一定是您最好的選擇。在大多數情況下，您可以根據自己的意願彎曲實體框架，但最終可能會自行實現與其他ORM一起提供的功能。