实体框架和存储过程不匹配的实体/模型

我真的在这里寻找最佳实践的建议，所以我将解释这种情况。我们有一个相当庞大的应用程序，它建立在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而不是实体框架会快得多启用延迟加载的调用。

非常感谢所有帮助

来源

2012-07-27 user351711

没有什么错用新的方法在你的仓库返回的NewsDataModel实例 - 它仍然在你的INewsRepository的范围，因为它是从新闻信息构建的数据类。否则，您将拥有您定义的每个数据模型的存储库。

来源

2012-07-29 16:44:42

实体框架和存储过程不匹配的实体/模型

回答

相关问题