方法有多少個參數才算多？

小弟有這樣一個方法，按頁大小和頁索引查詢產品，如下。

/// <summary>
/// 擷取產品
/// </summary>
/// <param name="manufacturerID">廠商ID，為null時不做查詢條件。</param>
/// <param name="categoryID">類別ID，為null時不做查詢條件。</param>
/// <param name="typeID">類型ID，為null時不做查詢條件。</param>
/// <param name="name">產品名稱，模糊比對。</param>
/// <param name="description">描述，模糊比對。</param>
/// <param name="pageSize">頁大小</param>
/// <param name="pageIndex">頁索引</param>
/// <returns></returns>
public DataTable GetProduct(int? manufacturerID, int? categoryID, int? typeID, string name, string description, int pageSize, int pageIndex)
{
return null;
}

可以看到小弟這個方法參數比較多，有7個，這時有人就說了:“這麼多參數，應該封裝成一個對象傳遞！”要寫成下面這個樣子。

public class QueryProduct
{
private int? manufacturerID;

/// <summary>
/// 廠商ID，為null時不做查詢條件。
/// </summary>
public int? ManufacturerID
{
get { return manufacturerID; }
set { manufacturerID = value; }
}

private int? categoryID;

/// <summary>
/// 類別ID，為null時不做查詢條件。
/// </summary>
public int? CategoryID
{
get { return categoryID; }
set { categoryID = value; }
}

private int? typeID;

/// <summary>
/// 類型ID，為null時不做查詢條件。
/// </summary>
public int? TypeID
{
get { return typeID; }
set { typeID = value; }
}

private string name;

/// <summary>
/// 產品名稱，模糊比對。
/// </summary>
public string Name
{
get { return name; }
set { name = value; }
}

private string description;

/// <summary>
/// 描述，模糊比對。
/// </summary>
public string Description
{
get { return description; }
set { description = value; }
}

private int pageSize;

/// <summary>
/// 頁大小
/// </summary>
public int PageSize
{
get { return pageSize; }
set { pageSize = value; }
}

private int pageIndex;

/// <summary>
/// 頁索引
/// </summary>
public int PageIndex
{
get { return pageIndex; }
set { pageIndex = value; }
}
} /// <summary>
/// 擷取產品
/// </summary>
/// <param name="query">查詢條件</param>
/// <returns></returns>
public DataTable GetProduct(QueryProduct query)
{
return null;
}

小弟心裡就想了 ，這才幾個參數，連10個都不到，封裝成一個對象有必要嗎？

下面是各自對問題的看法

應該封裝成對象：
1.不封裝成對象，代碼看起來很亂。
2.可維護性強，以後這個方法如果需要加查詢參數，只需要在QueryProduct類中增加一個屬性即可，方法不用改。
3.方法的參數越少越好，能少一個，絕不多一個。
4.方法的參數超過3個就要封裝成對象。

應該直接傳遞參數：
1.直接將查詢條件寫在方法參數上，可讀性強，便於後來人維護。
2.封裝成對象，項目中就需要增加一個對象，對象越多，越不利於維護，10個以內的參數，如果沒有特殊原因，不需要封裝成對象。
3.這裡的參數每一個都有業務意義，並不是要持久化到資料庫的實體屬性，在數量不多的時候，不應該封裝成對象。

下面是小弟對“應該封裝成對象”一派3個理由的回複
1.不封裝成對象，代碼看起來很亂。
一點都不亂，封裝成對象反倒增加了閱讀成本。
2.可維護性強，以後這個方法如果需要加查詢參數，只需要在QueryProduct類中增加一個屬性即可，方法不用改。
可維護性絕對沒有增強，反倒因為項目中多了一堆查詢條件對象，增加了閱讀成本，降低了維護性。當增加查詢條件時，改了查詢對象的定義，方法的參數就變了，方法也100%的變了，只是方法的代碼沒改，但方法的定義已經改了，這完全沒有優勢。都是改代碼，都是改方法的參數，都改變了方法的定義。
3.方法的參數越少越好，能少一個，絕不多一個。
這裡沒有一個參數是多餘的，少任何一個參數都不能滿足需求，方法的參數越少越好是毋庸置疑的，但絕不是用這種坑爹的方式減少參數。
4.方法的參數超過3個就要封裝成對象。
是否要將參數封裝成對象，不能只看參數的數量，還要看它的業務意義，作為資料載體的實體類，即使只有兩個屬性，也要用對象傳遞。但像這種，不需要持久化，而且每個參數都有各自的業務意義，沒有特殊原因，就應該寫在方法的參數列表裡。

關於這個問題，小弟希望看看大家是怎麼對待的，希望大家能在回複時除了表述自己的觀點，同時告知在項目中會採取哪種方式。