这个怎么样:通常建议不要向程序集的外部用户公开List对象，而是公开IEnumerable对象。但是在程序集中使用List对象要容易得多，因为您可以获得数组语法和所有其他List方法。因此，我通常有一个内部属性，公开要在程序集中使用的List。

欢迎对这种方法提出意见。

如果您正在编写一个DLL，它将大量复杂的功能封装到一个简单的公共API中，那么“internal”将用于不公开的类成员。

隐藏复杂性(又称封装)是高质量软件工程的主要概念。

在某些情况下，将类的成员设为内部是有意义的。例如，如果你想控制类的实例化方式;假设您为创建类的实例提供了某种类型的工厂。您可以将构造函数设置为内部的，这样工厂(位于同一个程序集中)就可以创建类的实例，但程序集中之外的代码不能。

然而，如果没有特定的原因，我不认为将类或成员设置为内部的有任何意义，就像没有特定的原因将它们设置为公共的或私有的一样没有意义。

如果Bob需要BigImportantClass，那么Bob需要让拥有项目A的人注册，以保证BigImportantClass将被编写以满足他的需求，测试以确保它满足他的需求，被记录为满足他的需求，并且将设置一个过程以确保它永远不会被更改，从而不再满足他的需求。

如果一个类是内部的，那么它就不需要经过这个过程，这为项目a节省了预算，他们可以把这些钱花在其他事情上。

内在的意义并不在于它让鲍勃的生活变得困难。而是它允许您控制Project A在特性、生命周期、兼容性等方面做出的昂贵承诺。

我有一个项目，使用LINQ-to-SQL的数据后端。我有两个主要的名称空间:Biz和Data。LINQ数据模型存在于数据中，并标记为“内部”;Biz命名空间拥有围绕LINQ数据类的公共类。

这就是数据。Client和business .Client;后者公开了数据对象的所有相关属性，例如:

private Data.Client _client;
public int Id { get { return _client.Id; } set { _client.Id = value; } }

Biz对象有一个私有构造函数(强制使用工厂方法)和一个内部构造函数，看起来像这样:

internal Client(Data.Client client) {
    this._client = client;
}

库中的任何业务类都可以使用它，但是前端(UI)无法直接访问数据模型，从而确保业务层始终充当中介。

这是我第一次真正使用内部，它被证明是非常有用的。

internal关键字的一个用途是限制程序集用户对具体实现的访问。

如果您有一个工厂或其他用于构造对象的中心位置，则程序集的用户只需处理公共接口或抽象基类。

此外，内部构造函数允许您控制实例化公共类的位置和时间。