我應該總是在函式中返回的 LINQ 查詢結果上呼叫 .ToArray 嗎？
在函式中返回 LINQ 查詢的結果時，我遇到了很多
Collection was modified; enumeration operation may not execute錯誤情況，就像這樣……（我應該添加函式作為介面的實現，結果留下這個模組以供使用在另一個。）Public Function GetTheFuzzyFuzzbuzzes() As IEnumerable(of FuzzBuzz) _ Implements IFoo.GetTheFuzzyFuzzBuzzes Return mySecretDataSource.Where(Function(x) x.IsFuzzy) End Function
.ToArray如果基礎數據有可能被更改，我是否應該在函式或屬性 getter 中返回 LINQ 查詢的結果時始終呼叫？我知道這樣做會降低效率，但我覺得這樣做是安全的，因此應始終避免出現時間耦合問題。編輯：
讓我更好地解釋問題域。
我們有一個基於圖形的主要關注領域的實現，這是一個優化問題。實體表示為圖形節點。用各種成本和其他參數加權的邊表示節點之間的關係。當使用者操作數據時，我們會創建不同的邊，並根據目前狀態評估他們可以採取的各種選項，從而為他們提供有關每個選項結果的回饋。其他使用者和程序對伺服器上的數據所做的更改會通過推送技術立即傳播到客戶端。我們使用了很多執行緒…
…所有這一切意味著我們有很多事情以非常非同步的方式發生。
我們的程序被分成模組（基於單一責任原則），有一個契約項目和一個在執行時解決的實施項目，這意味著我們嚴重依賴介面。我們通常使用 IEnumerable 在模組之間傳遞數據（因為它們是不可變的）。
不，我不會為此制定規則。
我理解你的擔心。呼叫方可能不知道它的操作會影響查詢結果。
在某些情況下，您確實無法做到這一點：
- 在某些範例中，這樣做會導致記憶體不足，例如無限可列舉，或者在每次迭代產生新計算的圖像的列舉器中。（我都有）。
- 如果您在查詢中使用
Any()或First()。兩者都只需要讀取第一個元素。所有其他工作都是徒勞的。- 如果您希望 Enumerables 與管道/過濾器連結。實現中間結果只是額外的成本。
另一方面，在許多情況下，當可以想像使用數組會產生影響查詢的副作用時，將查詢具體化為數組會更安全。
在編寫軟體時，有這樣的規則聽起來很有吸引力：“當你需要在 X 和 Y 之間做出選擇時，總是做 X”。我不相信有任何這樣的規則。也許在 15% 的情況下你真的應該做 X，在 5% 的情況下你肯定需要做 Y，而對於其餘的情況，這無關緊要。
對於剩下的 80% 的人來說，什麼都不做可能是合適的事情。如果您在
ToArray()任何地方插入，程式碼會錯誤地暗示這樣做是有原因的。