具有現有數據庫和具有多個源的類與手動存儲過程的實體框架

Question

實體框架和 ORM 的新手，但是可能有一個獨特的情況，我們正在考慮重構我們的應用程序的工作方式。

現在我們正在使用內存分布式緩存架構，基本上作為內存數據庫以相當低效和容易出錯的方式，與持久數據的同步，甚至緩存中的對象都不一致。

我們的想法是在某種程度上回到核心，要么集成某種形式的 ORM，如實體框架，要么在 SQL 中手動創建存儲過程，以引入創建復雜類所需的數據。

舉個例子，假設我們有一個SomeDashboard類，它有許多基於請求的Dashboard設置的屬性（存儲在 SQL 中），但是有許多與Dashboard相關的對象列表，例如Products或Reviews ，等等。人們可以編寫一個存儲過程，該過程將利用單個 DB 請求，該請求將拉回多個結果集以創建所有這些列表和對象值。

是創建存儲過程來實現這一點，還是創建多個存儲過程來分塊獲取數據（意味着更多的 SQL 調用），或者借助實體框架將所有對象拼湊在一起會更好嗎？

一些不穩定的東西，導致它需要經常重建； 擔心每次我們構建對象時都會有如此多的連接和如此多的請求來擴展數據庫。

也許這足以給出某種形式的方向； 我知道這充其量是模糊的。

與實體框架相關的問題的另一部分是——將所有內容映射到現有數據庫和類有多難？

從高層次上看……感覺內存中分布式緩存的集成沒有經過深思熟慮，並且以“搶先優化”的方式完成，導致問題多於解決； 所以回到根源並大量使用 SQL，然后在可能需要的地方有選擇地集成緩存，當 SQL 的性能成為問題時，這似乎是最好的主意。

Answer 1

關於問題的第一部分，您應該在實體框架上使用預先加載並讓它為您查詢數據。 這是使用 OR/M 的目的：您專注於應用程序代碼，而 OR/M 執行讀取和寫入數據到 SQL 數據源的原始部分。

查看這篇 MSDN 文章：加載相關實體。

關於...

與實體框架相關的問題的另一部分是——將所有內容映射到現有數據庫和類有多難

這沒有確定的答案。 這可能取決於您的數據庫設計。 如果您的數據庫是使用良好的關系設計實踐構建的，那么針對該數據庫配置 OR/M 通常會更容易。