在我看来，性能、名称空间污染等都是次要的。问问自己什么是合乎逻辑的。该方法在逻辑上操作类型的实例，还是与类型本身相关?如果是后者，则将其设置为静态方法。只有当它与不受您控制的类型相关时，才将其移动到实用程序类中。

Sometimes there are methods which logically act on an instance but don't happen to use any of the instance's state yet. For instance, if you were building a file system and you'd got the concept of a directory, but you hadn't implemented it yet, you could write a property returning the kind of the file system object, and it would always be just "file" - but it's logically related to the instance, and so should be an instance method. This is also important if you want to make the method virtual - your particular implementation may need no state, but derived classes might. (For instance, asking a collection whether or not it's read-only - you may not have implemented a read-only form of that collection yet, but it's clearly a property of the collection itself, not the type.)

如果函数在许多页面中共享，你也可以把它们放在一个基页类中，然后让所有使用该功能的asp.net页面继承它(函数也可以仍然是静态的)。

静态方法与实例方法 c#语言规范的静态成员和实例成员解释了这种差异。一般来说，静态方法可以提供比实例方法非常小的性能增强，但仅在某些极端情况下(有关详细信息，请参阅此回答)。

FxCop或代码分析中的CA1822规则规定:

在[将成员标记为静态]之后，编译器将向这些成员发出非虚拟调用站点，这将防止在 运行时，确保当前对象指针为 非空。这可以导致可测量的性能增益 性能敏感的代码。在某些情况下，访问失败 当前对象实例表示正确性问题。”

实用程序类 除非在设计中有意义，否则不应该将它们移到实用程序类中。如果静态方法与特定类型有关，就像ToRadians(双度)方法与表示角度的类有关一样，那么该方法作为该类型的静态成员存在是有意义的(注意，为了演示，这是一个复杂的示例)。

您应该在给定的场景中使用最易读和最直观的方法。

除了在最极端的情况下，性能参数并不是一个好的参数，因为实际发生的唯一事情是将一个额外的参数(this)推入到实例方法的堆栈中。

我相信这不会发生在您的情况下，但是在我不得不忍受维护的一些代码中，我看到了使用大量静态方法的“坏味道”。

不幸的是，它们是假定特定应用程序状态的静态方法。(当然，每个应用程序只有一个用户!为什么不让User类在静态变量中跟踪它呢?)它们是访问全局变量的光荣方法。它们还有静态构造函数(!)，这几乎总是一个坏主意。(我知道有一些合理的例外)。

然而，静态方法在排除域逻辑(实际上不依赖于对象实例的状态)时非常有用。它们可以使您的代码更具可读性。

只要确保你把它们放在正确的地方。静态方法是否侵入式地操纵其他对象的内部状态?能不能证明他们的行为属于其中一类呢?如果你没有正确地分离问题，你以后可能会头疼。

读起来很有趣: http://thecuttingledge.com/?p=57

ReSharper实际上并不是建议您将方法设置为静态的。 你应该问问自己，为什么这个方法在那个类中，而不是在它的签名中出现的类之一…

但ReSharper documentaion是这么说的: http://confluence.jetbrains.net/display/ReSharper/Member+can+be+made+static