在我的Repository方法中进行连接和其他复杂操作是一种好习惯吗?

时间:2012-02-15 16:20:35

标签: entity-framework repository-pattern abstraction

我正在用C#在ASP.NET MVC3中开发一个应用程序。

我目前正在构建由 ADO.NET EF 存储库类 MyDBRepository组成的 DAL

public class MyDBRepository
{
    MyDBEntities myDB;

    public MinervaDBRepository()
    {
        myDB = new MyDBEntities();
    }

    //methods
}

我仍然不确定MyDBRepository方法执行的查询的详细程度。我知道这个查询适用于存储库:

public IQueryable<Products> GetAllTickets()
{
     return myDB.products;
}

但是那些通过导航属性使用加入或使用其他类中的方法进行查询的用户呢?例子:

此方法检索在特定日期(数据库中存储为字符串的日期)被解雇的产品,并使用我创建的DateUtilities类:

public IQueryable<Products> GetProductsDismissed(DateTime date) 
{
        return myDB.products.Where(m => (string.IsNullOrEmpty(m.ProductDismissDate) || 
                                        Equals(m.ProductDismissDate, "-")) ? false :
              (DateTime.Compare(date, DateUtilities.ConvertToDateTime(m.ProductDismissDate)) > 0));
}

此方法使用导航属性执行加入以检索构成产品的所有部分(假设存在 1对多关系):

 public IQueryable<Products> GetAllProductParts(int productId)
    {
        return myDB.products.Where(m => Equals(m.ProductId, productId));
    }

它们是在存储库类中实现还是更好地将(一个或两个)移动到服务层

1 个答案:

答案 0 :(得分:1)

Repository封装了持久层,在那里实现与数据库相关的所有事情是正常的。实际上,实现对于应用程序的其余部分并不重要,这就是您首先使用存储库的原因。我建议改变的唯一方法是直接返回IEnumerable,而不是IQueryable。

它们之间存在差异,但在这种情况下无关紧要并且使用IQueryable意味着将来更改持久性访问更加困难(您可能希望切换到微观orm或更改其驱动程序不存在的RDBMS例如,支持IQueryable或仅使用云存储。