在 .NET 中可以将数组或列表作为属性返回吗？

我正在阅读 MSDN 上的一些文档，了解有关某些内容是否应该作为属性或方法实现的注意事项。我特别遇到了一条规则，对此我有疑问。

如果“操作返回一个数组”，请使用方法（而不是属性）。

页面在这里：在属性和方法之间进行选择 https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100).aspx

使用操作返回一个的方法 array 因为要保留内部数组，您必须返回 数组的深层副本，而不是对所使用的数组的引用 财产。这一事实，再加上开发人员使用的事实 属性就像字段一样，可能会导致效率非常低 代码。

我知道属性的 get 方法将返回对数组的引用，这将允许即使没有设置也可以更改数组。在他们给出的示例中，每次访问属性时，他们都会对数组进行深层复制，我想是为了避免发生这种情况的可能性，而这又是非常低效的。

如果属性只返回引用，而不进行所有复制，那么效率不会很低，对吗？而且使用方法而不是属性也不会自动保护列表不被修改。这几乎是相同的场景，您仍然需要深层副本。

使用属性并仅返回对数组的引用总是不好的做法吗？如果您希望调用者能够修改数组，或者您不关心他们是否修改数组，该怎么办？它仍然很糟糕吗？为什么？如果是的话，允许调用者修改的正确方法是什么？

您可以允许调用者通过属性修改内部数组吗？是的，当然，但是您将面临许多可能的问题。您如何处理这些问题以及您可以忍受什么取决于您。

MSDN 的建议在严格意义上是正确的。据说我见过List<T> and T[]之前从类返回的属性。如果您的类是一个非常简单的 POCO，那么这不是一个大问题，因为这些类只是原始数据，并且没有真正的业务逻辑可以影响。

也就是说，如果我要返回一个列表，并且我不想让任何人弄乱内部列表，我要么每次都返回一个深层副本，要么每次都返回一个ReadOnlyCollection，或迭代器。例如，我在很多地方缓存 Web 服务请求调用，当我返回缓存项时，我不希望调用者修改该数据，否则他们会修改我正在缓存的内容。因此，我在那里进行深层复制（这仍然比 Web 服务调用的开销更快）。

您只需要知道您的使用是否需要安全即可。该课程仅供内部使用吗？或者它是为了让更广泛的受众消费而设计的，但你不知道他们会用它做什么？这些类型的问题可能会影响你的回答。

抱歉，“这取决于”答案，但这确实取决于您的目标是什么以及班级的内部结构是否对变化敏感。

UPDATE您还可以返回一个迭代器，我会避免将 IEnumerable 作为超类向上转换返回，因为它可以向下转换，但如果您返回一个迭代器（例如使用 Skip(0)），那么您是安全的（除了仍然当然能够修改所包含的对象）。

例如：

public IEnumerable<T> SomeList 
{
    get { return _internalList.Skip(0); }
}

优于：

public IEnumerable<T> SomeList
{
    get { return _internalList; }
}

因为后者仍然可以被投射回List<T>或者无论它是什么，而第一个是迭代器并且无法修改。