装配体创建指南答案

【问题标题】：Assembly creation guidelines装配体创建指南
【发布时间】：2010-07-27 20:53:51
【问题描述】：

对于程序集中可以拥有的静态函数的数量是否有任何经验法则？

你如何识别一个函数是否需要是静态的和一个不需要是静态的函数？

【问题讨论】：

标签： .net architecture static assemblies frameworks

【解决方案1】：

嗯，没有经验法则 - 归结为设计论点。如果您要听 FxCop，如果方法不适用于类的实例成员，则该方法可以成为静态方法...

我更喜欢采用古老的定义，如果方法在类型之间共享而不是特定于类型的实例，则该方法应该是静态的。

此链接包含“何时使用”部分：

http://msdn.microsoft.com/en-us/library/79b3xss3(VS.80).aspx

【讨论】：

【解决方案2】：

一般来说，随着提供对组件的生活方式控制的 DI 和 IoC 容器的出现，我尽量将static 的使用保持在绝对最低限度。使用由 IoC 容器管理的“单例”组件，静态类和/或函数的价值和使用将减少到消失的水平。

也就是说，在程序集中可以拥有多少静态类型或成员并没有真正的限制。一个类型的静态成员由 CLR 存储在称为加载程序堆的东西上，而不是普通的 GC 堆，这些堆开始时相当小（我相信大约 32k）。鉴于此，它可能需要数千个静态类和/或填充加载程序堆的方法。

以下是我仍然使用静态成员或类的少数几种方式：

[ThreadStatic] static 必须提供线程单例行为的类中使用的字段
我的 .NET 配置类中的静态构造函数，例如 ConfigurationSection、ConfigurationElement 等。
- 我已经开始将这种配置类构造样式替换为简单地使用 [ConfigurationProperty()] 属性，虽然它会产生非常少量的额外开销，但它更简单且通常更简洁
真正的全局共享运行时数据...只是比使用 IoC 和额外类型更简单

【讨论】：

这个问题询问的是静态函数，而不是静态字段。我同意静态字段应该尽可能少，以 0 为理想值。但是静态方法是一个完全不同的问题！
我提到的静态字段只是表明我使用任何类型的静态的极少数情况，仅此而已。
我一直在考虑这个问题，但我完全不确定这是否成立。我知道，当您希望能够在启动时指定实现时，您需要有一个实例。话虽如此，在某些情况下这不是必需的甚至是不希望的功能，还有其他情况下我们确实想要一个实例但不想显示它。我举个例子：
假设我们有一个 Logger 类，它有一个 ILogger 类型的单例。静态构造函数获取 ILogger 实现的类型名并使用它。我们可以暴露这个单例，迫使调用者说Logger.Singleton.Log("Ok");。另一方面，我们可以编写一些静态传递方法来允许更自然的Logger.Log("Ok");"。这不是更好吗？
@Steven：我不会使用任何一种方法。我将通过 IoC 容器注入 ILogger 接口的实例，并让容器管理记录器的实例创建。一些记录器框架要求每个类都有一个实例，而另一些则提供一个可供所有东西使用的单一实例。无论如何，这是一个跨领域的问题，我根本不希望我的代码必须处理它。我只想能够使用 ILogger 的实例，不管它是如何创建的或它来自哪里，并进行日志记录。一个 IoC 容器为我解决了这个问题。这有意义吗？

【解决方案3】：

我认为经验法则是尽可能将其设为静态。换句话说，如果一个方法需要访问实例字段，那么它就不能是静态的。否则，应该是。

【讨论】：