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

使方法静态意味着您可以从类外部调用该方法，而无需首先创建该类的实例。这在使用第三方供应商对象或附加组件时非常有用。想象一下，如果你在调用con. writeline()之前必须先创建一个Console对象“con”;

在类中将方法标记为静态可以明显地表明它不使用任何实例成员，这有助于在浏览代码时了解这一点。

你不一定要把它移到另一个类中，除非它被另一个在概念上紧密关联的类所共享。

只是我的一点钱:将所有共享的静态方法添加到实用程序类中，您就可以添加

using static className; 

到您的using语句，这使得代码更快地输入和更容易阅读。例如，我在继承的一些代码中有大量所谓的“全局变量”。我没有在一个属于实例类的类中创建全局变量，而是将它们全部设置为全局类的静态属性。它完成了这项工作，虽然有些混乱，但我可以按名称引用属性，因为我已经引用了静态名称空间。

我不知道这是不是一个好的练习。关于c# 4/5，我有很多东西要学，还有很多遗留代码要重构，所以我只是想让Roselyn的技巧来指导我。

Joey

Just to add to @Jason True's answer, it is important to realise that just putting 'static' on a method doesn't guarantee that the method will be 'pure'. It will be stateless with regard to the class in which it is declared, but it may well access other 'static' objects which have state (application configuration etc.), this may not always be a bad thing, but one of the reasons that I personally tend to prefer static methods when I can is that if they are pure, you can test and reason about them in isolation, without having to worry about the surrounding state.

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

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.)