我有一个项目，使用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.

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

唯一一件事我曾经使用内部关键字是许可证检查代码在我的产品;-)

请记住，当有人查看您的项目名称空间时，任何定义为public的类都会自动显示在智能感知中。从API的角度来看，只向项目的用户展示他们可以使用的类是很重要的。使用internal关键字隐藏他们不应该看到的东西。

如果项目A的Big_Important_Class打算在项目外部使用，那么不应该将其标记为内部。

然而，在许多项目中，经常会有一些实际上只打算在项目中使用的类。例如，您可能拥有一个类，该类保存参数化线程调用的参数。在这些情况下，您应该将它们标记为内部的，如果没有其他原因，只是为了保护自己不受意外的API更改的影响。

在“使用尽可能严格的修饰符”规则的驱动下，我在需要访问的任何地方都使用internal，比如，从另一个类中访问方法，直到我显式地需要从另一个程序集访问它。

由于程序集接口通常比类接口的总和更窄，所以我在很多地方使用它。

我发现内部被过度使用了。您真的不应该只向某些类公开某些功能，而不向其他使用者公开。

在我看来，这打破了界面，打破了抽象。这并不是说永远不应该使用它，而是更好的解决方案是重构到不同的类，或者在可能的情况下以不同的方式使用。然而，这并不总是可能的。

The reasons it can cause issues is that another developer may be charged with building another class in the same assembly that yours is. Having internals lessens the clarity of the abstraction, and can cause problems if being misused. It would be the same issue as if you made it public. The other class that is being built by the other developer is still a consumer, just like any external class. Class abstraction and encapsulation isnt just for protection for/from external classes, but for any and all classes.

另一个问题是，许多开发人员会认为他们可能需要在程序集中的其他地方使用它，并将其标记为内部，即使他们当时并不需要它。另一个开发商可能会认为它就在那里。通常，在有明确的需要之前，您希望将其标记为私有。

但其中有些可能是主观的，我并不是说永远不应该使用它。只在需要的时候使用。