首先，我不认为这个问题是这些 SO 问题的重复：
我是否应该总是返回 IEnumerable<T> 而不是 IList<T>？ 和IEnumerable<T> 作为返回类型
众所周知，引入多层的主要目的是减少耦合。
我们必须为数据访问定义一些接口，我们的 BL 不应该关心 DAL 实现的细节。如果提到的接口返回IEnumerable<T>BL 不知道它只是一个静态的IEnumerable还是延迟执行的东西。同时，这个特定的细节会极大地影响性能，并且根据实现需要不同的编码。好吧，在我们要多次迭代集合的情况下，
可以调用.ToList()each 。IEnumerable但是由于不必要的新列表实例化，这会降低静态集合的性能。
所以我试图了解哪种方法更好。
更通用且性能可能更低与更耦合 - 更高性能。我想，没有灵丹妙药，但它可能是我错过的其他方法。
所以我试图了解哪种方法更好：更通用且性能更低与更耦合和更高性能。
首先，虽然这是一个有趣的权衡，但在这种情况下，我认为相关的权衡实际上是正确的还是不正确的，这肯定胜过任何性能问题。延迟执行查询通常具有它为您提供最新查询结果的属性，而调用ToList为您提供查询结果的过去版本的快照。肯定有一种情况是正确的，另一种是不正确的。
其次，假设您已经处理了正确性问题并且确实需要进行性能权衡，那么您真正想要做出的权衡是：更普遍和不可接受的性能与更多耦合和可接受的性能，在这一点上，您很清楚您有选择性能可以接受的那个。
如果两者都具有可接受的性能并且一个比另一个慢几纳秒，或者消耗的内存比另一个多几个字节，并且两者都是正确的，那么谁在乎你选择哪一个呢？把宝贵的时间花在思考其他事情上。如果两者都没有可接受的性能，那么你有一个更大的问题需要解决。
如果从概念上讲，让调用者知道方法的返回类型是 aList而不是 an 很重要IEnumerable（例如，要知道多次迭代它不会产生负面影响），那么您应该返回 a List。取而代之的是，返回接口是一种说法，“实现是什么并不重要”。如果实现确实很重要，那么不要使用接口（在那种特定情况下）。
我找到了很好的解决方案：DAL 中的所有返回类型（in 接口）都不能IEnumerable<>（或不能是接口类型）。但是可以在BL中使用。这可以是建筑师的决定。