问题探究：静态类以及静态方法的利弊
0
悬赏园豆：50
[待解决问题]
拿到在一个.Net MVC Web项目，发现%80的类以及方法都是Static的，总是感觉有点别扭，
如MSSqlHelper这个也就属于正常了，但是别的业务逻辑类基本上都是静态的，连EntityFramework的相关的方法和和类都分装成静态的类和方法。 这样做，有什么利弊？
还请各位大虾一起来指点下！
---园豆多多，参与讨论，就有豆豆……
所有回答(7)
0
可能一个业务处理就一个方法，项目里的业务都是属于那种流程性、事物性的吧
恩，有点道理……！
这里之所以没有给具体的代码，就是想大家来一起想想，自己在项目中怎么用实例类和静态类以及方法的……！
@吴哥-Angkor: 我刚毕业那会，做一个铁路货站的信息系统，里面的所有业务处理方法都在BF（Business Flow）层，然后这个层的所有的类都只有方法，没任何属性和成员
0
Static的特点就是共享，不能创建实例，也确保了类的安全性
Static类型在编译时就会分配内存，而且不会被GC回收，除非AppDomain被卸载，或者程序关闭。
不会被GC回收
那么如果是个比较大的项目，是不是会给系统带来过多的负载，相对于实例？如果没有特殊的处理（AppDomain被卸载）
@吴哥-Angkor:
80%的类都是静态想想这也太恐怖了吧，这样处理应该是不太合理的。把static 用得过度了
@Zery: 这样的话，可能会出现弊端？
0
实例化是需要代价的，个人喜欢静态的方法。
如果你在做一个比较大的项目时，你又是怎么选择静态和实例的呢？
0
我个人觉得一些工具性质的类用static，其它就别用static。
谢谢！
0
个人习惯，用实例方法来实现一个静态方法感觉技巧性要高许多，人们都比较懒。。。
惰性……人类的通病……！ 静态类的负载应该很大……
0
在CLR中，静态方法和实例方法都是存储在类型对象（每一个类都有唯一的一个类型对象）中，因此，只要是定义一个方法，不管是实例还是静态的方法，都会占用相同的空间，从内存这点考虑，它们等同，但是调用实力方法得初始化一个对象，所以调用方法的时候肯定是静态方法省空间（省去了实例的空间），省时间（省去了实例化的时间）。所以如果一个方法能把它定义成静态的就尽量定义为静态的
如果是一个大的应用系统的话，考虑的功能的扩展和稳定，从架构设计上看待这个问题呢？
@吴哥-Angkor: 静态方法的话 类就成静态了耶 然后就成工具类了 怎么面向对象给儿子用 多态呢
貌似公司的东西只有通用的工具类才是静态的 还有一些不变又不想存数据库的配置常量
CLR 的那本书看了没有 觉得如何
