c# - 在存储库界面中使用可选参数会被认为是糟糕的设计吗？

Question

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

例如，如果我有以下存储库:

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<T> 而不是 IQueryable<T> 来避免的)。

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

Answer 1

我会警告不要使用可选参数，因为默认值将被编译到调用程序中。这意味着如果默认值发生变化，任何使用原始默认值的代码都需要重新编译。

如果将来您决定 null，这在您的特定示例中可能会成为问题不是有效值，更改了默认值，并开始抛出 ArgumentNullException如果null已传入。任何使用您的界面的代码都必须重新编译或可能开始抛出 ArgumentNullExceptions .

您可以阅读关于此的更好解释 here和 here .

The key take-away from this: once you expose a default parameter value on a public method, you can never change it without recompiling all clients that depend on it. For library writers, this never means never ever.