考虑到确切的两个代码片段，我认为版本1更好，因为它可以更有效。假设有很多产品，调用者希望将其转换为dto。

var dtos = GetAllProducts().Select(ConvertToDto).ToList();

在版本2中，首先创建一个Product对象列表，然后创建另一个ProductDto对象列表。版本1没有Product对象的列表，只构建了所需的ProductDto对象的列表。

Even without converting, Version 2 has a problem in my opinion: The list is returned as IEnumerable. The caller of GetAllProducts() does not know how expensive the enumeration of the result is. And if the caller needs to iterate more than once, she will probably materialize once by using ToList() (tools like ReSharper also suggest this). Which results in an unnecessary copy of the list already created in GetAllProducts(). So if Version 2 should be used, the return type should be List and not IEnumerable.

Yield return对于需要遍历数百万个对象的算法来说非常强大。考虑以下示例，您需要计算可能的拼车行程。首先我们生成可能的行程:

    static IEnumerable<Trip> CreatePossibleTrips()
    {
        for (int i = 0; i < 1000000; i++)
        {
            yield return new Trip
            {
                Id = i.ToString(),
                Driver = new Driver { Id = i.ToString() }
            };
        }
    }

然后迭代每一次旅行:

    static void Main(string[] args)
    {
        foreach (var trip in CreatePossibleTrips())
        {
            // possible trip is actually calculated only at this point, because of yield
            if (IsTripGood(trip))
            {
                // match good trip
            }
        }
    }

如果您使用List而不是yield，您将需要为内存分配100万个对象(~190mb)，而这个简单的示例将花费~1400ms运行。但是，如果使用yield，就不需要将所有这些临时对象都放到内存中，而且算法速度会大大加快:本例只需要大约400ms就可以运行，完全不消耗内存。

在这种情况下，我将使用代码的版本2。由于您拥有可用产品的完整列表，而这正是此方法调用的“消费者”所期望的，因此需要将完整的信息发送回调用方。

如果该方法的调用者一次只需要“一个”信息，而下一个信息的消耗是按需的，那么使用yield return将是有益的，它将确保当一个单位的信息可用时，执行命令将返回给调用者。

可以使用yield return的例子如下:

复杂的，一步一步的计算，调用者每次等待一个步骤的数据 在GUI中分页-用户可能永远不会到达最后一页，只有子集的信息需要在当前页面上公开

为了回答你的问题，我会使用版本2。

我知道这是一个老问题，但我想提供一个例子，说明如何创造性地使用yield关键字。我真的从这个技巧中受益良多。希望这将有助于任何人谁偶然遇到这个问题。

注意:不要认为yield关键字仅仅是构建集合的另一种方式。收益率的很大一部分力量来自于这样一个事实，即在执行过程中暂停 方法或属性，直到调用代码遍历下一个值。以下是我的例子:

使用yield关键字(与Rob Eisenburg的Caliburn一起使用)。微协程实现)允许我像这样表达对web服务的异步调用:

public IEnumerable<IResult> HandleButtonClick() {
    yield return Show.Busy();

    var loginCall = new LoginResult(wsClient, Username, Password);
    yield return loginCall;
    this.IsLoggedIn = loginCall.Success;

    yield return Show.NotBusy();
}

这将做的是打开我的BusyIndicator，在我的web服务上调用Login方法，将我的IsLoggedIn标志设置为返回值，然后关闭BusyIndicator。

Here's how this works: IResult has an Execute method and a Completed event. Caliburn.Micro grabs the IEnumerator from the call to HandleButtonClick() and passes it into a Coroutine.BeginExecute method. The BeginExecute method starts iterating through the IResults. When the first IResult is returned, execution is paused inside HandleButtonClick(), and BeginExecute() attaches an event handler to the Completed event and calls Execute(). IResult.Execute() can perform either a synchronous or an asynchronous task and fires the Completed event when it's done.

LoginResult看起来像这样:

public LoginResult : IResult {
    // Constructor to set private members...

    public void Execute(ActionExecutionContext context) {
        wsClient.LoginCompleted += (sender, e) => {
            this.Success = e.Result;
            Completed(this, new ResultCompletionEventArgs());
        };
        wsClient.Login(username, password);
    }

    public event EventHandler<ResultCompletionEventArgs> Completed = delegate { };
    public bool Success { get; private set; }
}

它可能有助于设置类似这样的东西，并逐步执行以观察发生了什么。

希望这能帮助到一些人!我真的很喜欢探索不同的收益使用方式。

作为理解何时应该使用yield的概念性示例，假设方法ConsumeLoop()处理ProduceList()返回/产生的项:

void ConsumeLoop() {
    foreach (Consumable item in ProduceList())        // might have to wait here
        item.Consume();
}

IEnumerable<Consumable> ProduceList() {
    while (KeepProducing())
        yield return ProduceExpensiveConsumable();    // expensive
}

如果没有yield，对ProduceList()的调用可能需要很长时间，因为你必须在返回之前完成列表:

//pseudo-assembly
Produce consumable[0]                   // expensive operation, e.g. disk I/O
Produce consumable[1]                   // waiting...
Produce consumable[2]                   // waiting...
Produce consumable[3]                   // completed the consumable list
Consume consumable[0]                   // start consuming
Consume consumable[1]
Consume consumable[2]
Consume consumable[3]

使用yield，它会重新排列，有点交错:

//pseudo-assembly
Produce consumable[0]
Consume consumable[0]                   // immediately yield & Consume
Produce consumable[1]                   // ConsumeLoop iterates, requesting next item
Consume consumable[1]                   // consume next
Produce consumable[2]
Consume consumable[2]                   // consume next
Produce consumable[3]
Consume consumable[3]                   // consume next

最后，正如之前许多人已经建议的那样，您应该使用版本2，因为您已经有了完整的列表。

这有点离题了，但由于这个问题被标记为最佳实践，我将继续发表我的意见。对于这种类型的东西，我非常喜欢把它变成一个属性:

public static IEnumerable<Product> AllProducts
{
    get {
        using (AdventureWorksEntities db = new AdventureWorksEntities()) {
            var products = from product in db.Product
                           select product;

            return products;
        }
    }
}

当然，它更像一个样板，但使用它的代码将看起来更干净:

prices = Whatever.AllProducts.Select (product => product.price);

vs

prices = Whatever.GetAllProducts().Select (product => product.price);

注意:我不会对任何可能需要一段时间才能完成工作的方法这样做。