在存儲庫接口中使用可選參數會被視為糟糕的設計嗎？

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不是有效值，更改了默認值，並且如果傳入null則開始拋出ArgumentNullException ，這可能是您的特定示例中的問題。任何使用您的接口的代碼都必須重新編譯或可能開始拋出ArgumentNullExceptions 。

你可以在這里和這里閱讀更好的解釋。

關鍵是：在公共方法上公開默認參數值后，如果不重新編譯依賴於它的所有客戶端，就永遠不能更改它。 對於圖書館作家來說，這絕不是永遠不會的 。

Answer 2

我決定將這兩個參數用作存儲庫本身的屬性。 考慮到默認值將被編譯到調用者中的事實，以及在每個可能的存儲庫上的每個方法上寫這些參數的事實可能是乏味的。

Answer 3

對於我的編程風格，有很多lambda的可選參數都不太合適。

C＃4.0功能 - 命名和可選參數 - 呃，不，謝謝： http ： //blogs.ijw.co.nz/chris/index.php/2010/05/c-4-0-features-named-optional-parameters-嗯，沒有，謝謝/

作為一個更好的設計，我會使用元組作為參數。 或命名類，使用默認字段值聚合頁面和順序。 對不起，這當然是主觀的。