我有一个项目，使用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的另一个原因是混淆了二进制文件。混淆器知道打乱任何内部类的类名是安全的，而公共类的名称不能打乱，因为这可能破坏现有的引用。

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

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

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

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

根据经验，有两种成员:

公共表面:从外部组件可见(公共的、受保护的和内部受保护的): 调用者不受信任，因此需要参数验证、方法文档等。 私有表面:从外部程序集(私有和内部或内部类)中不可见: 调用者通常是可信的，所以参数验证、方法文档等可以省略。

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

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