在构建非托管代码的包装器时，internal关键字被大量使用。

当你有一个基于C/ c++的库，你想要DllImport，你可以导入这些函数作为一个类的静态函数，并使他们内部，所以你的用户只能访问你的包装器，而不是原始的API，所以它不能乱动任何东西。函数是静态的，您可以在程序集中的任何地方使用它们，用于您需要的多个包装器类。

你可以看看Mono。Cairo，它是使用这种方法的Cairo库的包装器。

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

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

当你的类或方法不完全符合面向对象范式，它们做危险的事情，需要从你控制下的其他类和方法调用，而你不想让其他人使用它们时。

public class DangerousClass {
    public void SafeMethod() { }
    internal void UpdateGlobalStateInSomeBizarreWay() { }
}

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

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

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

我有一个项目，使用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)无法直接访问数据模型，从而确保业务层始终充当中介。

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

其思想是，当您设计一个库时，只有打算从外部(由库的客户端)使用的类应该是公共的。这样你就可以隐藏

可能在未来的版本中更改(如果它们是公开的，您将破坏客户端代码) 对客户是无用的，可能会造成混乱 不安全(所以使用不当会严重破坏你的库)

etc.

如果你在开发内部解决方案，那么使用内部元素就不是那么重要了，因为通常客户会经常与你联系，并且/或访问代码。不过，它们对库开发人员来说相当重要。