我應該如何使用對性能敏感的數據訪問？

因此，我有一個應用程序需要非常快速地訪問大量的數據，我們正處於對數據庫進行大量重新設計的階段，這爲重新編寫數據訪問提供了良好的操作性層如果nessersary！我應該如何使用對性能敏感的數據訪問？

當前在我們的數據訪問層中，我們使用手動創建的實體以及普通SQL來填充它們。這很快，但是這項技術真的變老了，我擔心我們錯過了一個更新的框架或數據訪問方法，在整潔和可維護性方面可能會更好。

我們已經看到了實體框架，但經過一番研究，似乎它所提供的ORM的好處並不足以證明性能較低，而且我們的某些查詢變得越來越複雜，我確信性能與英孚將成爲更多的問題。

所以這是堅持我們目前的數據訪問方法，還是有一些比手動創建和維護實體有點整潔的情況？

我想這是竊聽我是剛剛打開我們的數據層的解決方案，看大量的實體，所有這些都需要保持正是在數據庫中，這有時是一個大量的工作線的事情，但那麼也許這就是我們爲演出付出的代價？

任何想法，意見和建議，非常感謝！ :)

謝謝，

安迪。

** **更新

忘了提，我們真的需要能夠使用Azure的（客戶的需求），目前阻止我們使用存儲過程來處理。 ** Update 2 **實際上，我們有一個用於DAL的接口層，這意味着我們可以創建一個Azure實現，它只是覆蓋來自Local實現的不適合Azure的數據訪問方法，所以我想我們可以使用存儲過程針對性能敏感的本地數據庫，並使用EF作爲雲。

來源

2011-01-19 Andy

我會使用一個ORM層（實體框架，NHibernate等）來管理各個實體。例如，我會使用ORM /實體圖層來允許用戶對實體進行編輯。這是因爲將您的數據視爲實體在概念上更簡單，並且ORM使得編寫這些東西非常容易，而無需編程任何SQL。

對於事物的批量報告方面，我絕對不會使用ORM層。我可能會專門爲標準報告創建一個單獨的類庫，它可以自己創建SQL語句或調用sprocs。 ORM實際上並不適用於批量報告，您將永遠無法通過手動編碼SQL獲得通過ORM查詢的相同靈活性。

來源

2011-01-19 11:29:47 David

如此有效地有兩個DAL的？一個用於使用普通SQL的性能數據，另一個用於使用EF的其他bog標準內容？性能DAL可以重複使用由EF創建的實體嗎？因此，兩個DAL都會將相同的對象返回給BLL？ – Andy 2011-01-19 11:50:34

是的，我提出了並排系統，儘管在我的辯護中，他們使用專爲他們的特定目的而設計的工具來完成不同的事情。我會主張不使用EF（和實體）進行報告，因爲EF會根據您的報告編寫來綁定您的手。有時低層次的東西感覺更簡單，因爲它更直接。 – David 2011-01-19 16:05:24

值得一提的是，通過SQL/sprocs進行報告不會返回實體（除非您爲實體編程執行了大量繁瑣的數據集）。但我認爲這不重要。（雖然它可能對你很重要。） – David 2011-01-19 16:10:17

存儲過程的性能。易於開發的ORM

當您運行不好時，您是否想要解決一些不透明生成的SQL問題？那會產生幾次往返行程，人們會做？或者堅持使用錯誤的數據類型？

來源

2011-01-19 11:34:53 gbn

您可以嘗試使用mybatis（以前稱爲ibatis）。它允許你將sql語句映射到域對象。通過這種方式，您可以完全控制正在執行的SQL，並同時獲得乾淨定義的域模型。

來源

2011-01-19 11:58:43

不排除普通的舊ADO.NET。它可能不如EF4那麼髖關節，但它只是起作用。

使用ADO.NET你知道你的SQL查詢將會是什麼樣的，因爲你對他們100％的控制什麼。 ADO.NET迫使開發人員去思考SQL，而不是回到ORM上去做魔術。

如果性能是高的名單上，我很不願意承擔任何ORM尤其是EF這是新的現場和高度複雜的依賴關係。 ORM的加速開發（稍微），但會使你的SQL查詢性能很難預測，並且在大多數情況下比手動SQL /存儲過程慢。

您也可以單元測試SQL /存儲的特效獨立於應用程序，因此隔離性能問題或者DB /查詢相關或應用相關。

我猜你是使用ADO.NET在DAL了，所以我建議你投資的時間和精力在重構它，而不是把它扔出去。

來源

2011-01-27 09:16:28 saille

我應該如何使用對性能敏感的數據訪問？

回答

相關問題