2010-07-18 49 views
1

我們有包含在所謂的「Bll.dll」
Bll.dll返回列表<的一些方法一個類庫項目的業務方法的web項目> ...從源
- 我不記得現在 - 告知返回集合<>比返回列表好<>
這是有效的嗎?
請注意,我不會讓從BLL方法返回值的任何過程..只是在網頁中從返回收集<T>從性能不同的返回列表<T>?

回答

4

Collection<T>實現,IIRC查看它,作爲一個包裝的IList<T>,它的默認實現是圍繞List<T>。因此Collection<T>至少有一個比List<T>更抽象,但通常這不會是一個瓶頸。事實上,你可能會考慮返回IList<T>

編輯:這裏是Collection<T>構造,反射器的禮貌:

public Collection() 
{ 
    this.items = new List<T>(); 
} 

所以事實上,這種包裝的抽象層。 這一方面是你可以通過繼承Collection<T>(當直接使用List<T>或通過子類化時不可能,因爲沒有有趣的virtual方法)而添加自己的驗證等。

要考慮的另一件事是,它們將具有相同的總體性能的「O」(假設您使用默認的List<T>實現)。索引查找將是O(1)

+0

你的意思是IIRC?你有沒有看到IList 是我最好的? – 2010-07-19 05:50:42

+1

相關網站:http://zh.wiktionary.org/wiki/IIRC;是的,除非你有特定的需要使用具體的返回類型,'IList '是一個不錯的選擇 - 它可以讓你靈活地使用任何實現,而客戶端不必知道它。因此,您可以**將其公開爲** IList ',但現在返回'List ',以後可以自由地替換其他任何東西('Collection ','MyCustomFooCollection'等)。 – 2010-07-19 06:31:37

2

你真的應該只返回符合設計你的API時設定的目標接口。例如,如果你只希望你的客戶迭代一個集合,然後返回IEnumerable<T>。至於你的具體問題,我覺得ICollection<T>是沒用的,因爲它缺乏索引器。

+0

你怎麼知道客戶端只想迭代集合?也許他們想用它作爲一個集合。或者也許只需要點數。如果你以後想要公開其他屬性呢?由於這些原因和其他原因,微軟的框架設計指導方針建議完全相反。 – 2010-07-18 22:47:51

+2

@Jonathon - 臃腫的框架問題的一部分是,設計師嘗試覆蓋所有用例,而不是專注於一件好事。如果您願意,請隨意按照Microsoft指導方針進行盲目追蹤。 – ChaosPandion 2010-07-18 22:52:29

+0

如果你有一個Collection 反正你只是爲你的客戶提供一個IEnumerable來減少膨脹。事實上,你會增加花費,因爲現在他們不得不創建自己的收藏集或檢測到你給了他們一個並投射它。 – 2010-07-19 07:20:50

0

更好的可能不適用於表演,但只適用於返回類型。

在這種情況下,不容易說什麼更好,在我看來,依賴方法「localy」的用法是我們操作的返回類型。

0

返回List的問題是調用者可以修改它。如果你想連接一些通知機制(「每當調用者向它添加一個新對象時通知被調用者」),你不能作爲一個列表是死路一條。

返回一個Collection/ICollection允許你創建你自己想要的實現。

基本上,一個列表意味着你被困在一個角落,你不能逃脫沒有突然的變化。

So Collection/ICollection/IList是首選。

請參閱this questionthis article

+0

您可以返回列表的AsReadOnly,這是一個IList 。當然,這個薄包裝可能會有一些微不足道的開銷。 – 2010-07-19 01:11:00

0

最好的辦法是公開一個像CustomerCollection這樣的強類型類。這樣你可以在稍後添加屬性和方法。

現在你不應該公開一個列表,但我個人認爲它沒有問題。

+0

爲什麼不使用泛型? – 2010-07-19 01:10:30

+0

那麼CustomerCollection會繼承ObjectModel.Collection 。至於列表,我知道的唯一版本是列表。 – 2010-07-19 01:29:19

+0

那麼,你必須明確聲明一個CustomerCollection,從Collection 中派生出來,但我不確定那些買你回來的IList 。 – 2010-07-19 01:42:27