題
需要建議遷移asp.net mvc 3應用程序的幾個模塊：現在我們正在使用EF和POCO類，但是在將來對於一些性能驅動的模塊我們需要轉移到ADO.NET或其他一些ORM工具（可能是DAPPER 。淨）。
我們現在面臨的問題是：我們的視圖依賴於通過EF加載的Collection類，我應該使用什麼策略來加載這些實體類與EF與其他ADO.NET或ORM工具完全相同的方式。
我想要的是能夠在數據訪問層以最小的變化在EF和ADO.NET之間切換，因為我不希望我的視圖通過它來實現。
一般承認的答案
您應該使用存儲庫設計模式來隱藏數據訪問層的實現。無論您使用何種數據訪問層，存儲庫都將返回相同的POCO並具有相同的操作合同。現在，如果您使用的是沒有虛擬方法來實現延遲加載的真實POCO，這樣可以正常工作。您需要顯式處理對實體的依賴集合的加載以使其工作。
熱門答案
到目前為止我所看到的，從一個ORM / DAL到另一個ORM / DAL的無縫過渡是一種錯覺。凱文建議的存儲庫模式是一個很好的幫助，甚至是先決條件（+1）。但是，每個ORM在域層中都有足跡。使用EF，您可能會使用虛擬屬性，可能是數據註釋，或者很容易忘記，一個易於適應的驗證框架（並且忽略其他沒有的驗證框架）。您可以依賴EF在連接表之間進行映射的能力。由於EF，可能有些事情你不願意 （但想做）。
（更不用說在EF上下文中執行腳手架的工具。這會使鎖定更加緊密。）
在你的情況下我可能會做的一些事情（如果我為你陳述明顯的話，請原諒我）
- 最佳使用EF。 （最佳映射，最佳關聯，......）為未來做好準備是好的，但它很容易退化為YAGNI模式。
- 精通linq + EF：有很多方法可以通過EF不必要地殺死性能。假設EF足夠好！
- 繼續尋找高性能的替代方案，例如使用存儲過程，並行化，後台處理和/或減少數據量，並在需求（功能和非功能）足夠清晰時選擇一個。
- 也許引入一個帶有DTO的抽象層，它現在可以提供你的觀點，並且將來可以很容易地被另一個ORM或ADO實現。
- 將POCO作為接口公開，稍後可以由其他對象實現。