Question

我真的在这里寻求有关最佳实践的建议，所以我将解释这种情况。我们有一个相当大的应用程序构建在POCO和EF 4之上，具有复杂的数据库。虽然我们对实体框架感到满意，但可以通过以下方案（非常简化）进行明确的性能改进。

我们有一个名为News的表，其中有一组用户已将其添加到他们的收藏夹中，并由用户添加了一组评级（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，这可能是多次调用，但是sproc返回的数据与上面的新闻的POCO类不匹配。

我们一直在努力研究最佳方法，因为我们有一个INewsRepository，它可以返回与实体框架相关的类，也可以返回我们用存储过程和ADO.NET填充的自定义DataModel类。这感觉不对，如果您希望单个对象具有从多个表构建的数据，并且使用sproc比实体框架快得多，我会感谢任何有关处理这些场景的最佳方法的经验或见解。在启用延迟加载的情况下调用。

非常感谢您的帮助

Answer 1

在您的存储库返回NewsDataModel的实例时，新方法没有任何问题 - 它仍然在您的INewsRepository范围内，因为它是根据新闻信息构建的数据类。否则，您将拥有您定义的每个数据模型的存储库。

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

1 个答案: