在存储库界面中使用可选参数是否会被视为糟糕的设计？

发布于 2024-10-02 21:00:52 字数 1075 浏览 1 评论 0原文

我创建了两个类来外部控制存储库上的页码 (Page) 和排序 (Order)。该存储库公开 IEnumerable 而不是 IQueryable，因为我希望存储库具有很强的可测试性。

举例来说，如果我有以下存储库：

interface IUserRepository
{
    public IEnumerable<User> GetAll();
}

如果我希望调用者控制响应的子集，他们将需要传入页面/订单。所以首先想到的是添加重载：

interface IUserRepository
{
    IEnumerable<User> GetAll();
    IEnumerable<User> GetAllOrderedAndPaged(Order order, Page page);
}

我发现的问题是我必须创建多个重载，我发现这非常乏味。

我正在考虑（但不确定）做的是让 Order 和 Page 成为可选参数：

interface IUserRepository
{
    IEnumerable<User> GetAll(Order order = null, Page page = null);
}

这样调用代码可以轻松排序/分页，但不能使用主查询（这是我试图通过公开IEnumerable而不是IQueryable来避免的）。

这看起来是一个好还是坏的设计？我知道这可能被认为有点主观，但我正在尝试看看这是否存在功能错误。主要的关键是我的存储库是可测试的，并且调用者不能过多地玩弄/更改查询。我想既然排序/排序对于返回的数据集来说是一个非常常见的任务，为什么不将它们合并到存储库界面的设计中呢？同样，在测试时，我只关心返回正确的数据集，但调用者可以说“现在，给我这个页面/数据的有序子集”。

原文

I have created two classes to externally control page number (Page) and ordering (Order) on a repository. The repository exposes IEnumerable<T> and not IQueryable<T> since I want the repository to have strong testability.

Say, for example, if I had the following repository:

interface IUserRepository
{
    public IEnumerable<User> GetAll();
}

If I want the caller to control the subset of the response, they would need to pass in the page/order. So first thought would be to add overloads:

interface IUserRepository
{
    IEnumerable<User> GetAll();
    IEnumerable<User> GetAllOrderedAndPaged(Order order, Page page);
}

The problem I find with this is that I have to create multiple overloads which I find to be pretty tedious.

What I'm thinking (but not sure) of doing is having Order and Page be optional parameters:

interface IUserRepository
{
    IEnumerable<User> GetAll(Order order = null, Page page = null);
}

This way the calling code can easily sort/page, but not play with the main query (which is what I'm trying to avoid by exposing IEnumerable<T> instead of IQueryable<T>).

Does this seem like a good or bad design? I know that could be considered a bit subjective, but I'm trying to see if there is functionally wrong with this. The main key is that my repositories are testable and the caller can't play around/change the query too much. I figured that since sorting/ordering are a very common task for a returning set of data, why not incorporate them into the design of the repository interface. Again, when testing, I only care that the right set of data is returned, but the caller can say "Now, give me this page/ordered subset of the data".

分享到QQ

分享到微博