我真的在這裏尋找最佳實踐的建議,所以我將解釋這種情況。我們有一個相當龐大的應用程序,它建立在POCO和EF 4的基礎上,具有複雜的數據庫。雖然我們對實體框架感到滿意,但是在下面的情況下(比較簡單)會有明顯的性能改進。實體框架和存儲過程不匹配的實體/模型
我們有一個叫做新聞具有已經將其添加到自己的收藏夾的用戶集合和評級(1 - 5)的一個集合表的用戶,例如:
public class News
{
public virtual int NewsId;
public virtual string Title;
.......etc....
public virtual ICollection<User> UserFavourites { get; set; }
public virtual ICollection<Rating> Ratings { get; set; }
}
我們寫了一個存儲程序,該程序爲用戶返回新聞並允許我們返回它是否是最愛,以及它是否已被用戶評分,我們正在請求數據以及當前新聞評分,而不是使用EF從ICollections中構建此數據我們最終得到一個像下面這樣的對象。
public class NewsDataModel
{
public int NewsId;
public string Title;
.......etc....
public bool IsFavourite { get; set; }
public bool IsRated { get; set; }
public double Rating { get; set; }
}
存儲過程是更快,一個單一的數據庫命中,而不是與EF延遲加載可能是多個電話,但通過存儲過程的新聞的POCO類,這是上面的不匹配返回的數據。
我們一直在努力鍛鍊最好的方式來推進這一點,因爲我們有一個INewsRepository,它可以返回實體框架相關的類或我們正在使用存儲過程和ADO.NET填充的自定義DataModel類。這種感覺不正確,我希望任何有關其他人的建議或見解可以體驗到當您希望單個對象具有從多個表構建的數據時,處理這些場景的最佳方法,而使用sproc而不是實體框架會快得多啓用延遲加載的調用。
非常感謝所有幫助