Руководство по созданию сборки

Question

Есть ли эмпирическое правило относительно количества статических функций, которые вы можете иметь в сборке?

Как узнать, должна ли функция быть статической, а функция не должна быть статической?

Answer 1

Ну, эмпирического правила не существует - это сводится к аргументу дизайна. Если вы будете слушать FxCop, метод будет статичным, если он не работает на экземплярах класса ...

Я предпочитаю использовать старое определение, метод должен быть статическим, если он является общим для типа, а не специфичным для экземпляра типа.

Эта ссылка содержит раздел «Когда использовать»:

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

Answer 2

Я думал, что эмпирическое правило, если можно, сделать его статичным.Другими словами, если метод должен получить доступ к полям экземпляра, он не может быть статическим.В противном случае это должно быть.

Answer 3

Вообще говоря, с появлением контейнеров DI и IoC, которые обеспечивают контроль компонентов над образом жизни, я стараюсь ограничить использование static до абсолютного минимума. При использовании одноэлементных компонентов, управляемых контейнером IoC, ценность и использование статических классов и / или функций уменьшаются до исчезающих уровней.

Тем не менее, на самом деле нет ограничений на количество статических типов или элементов, которые вы можете иметь в сборке. Статические члены типа хранятся в чем-то, называемом кучами загрузчика, а не обычной кучей GC, CLR, и эти кучи начинаются довольно небольшими (я думаю, около 32 тыс.). Учитывая это, вероятно, потребуется много тысяч статических классов. и / или методы заполнения кучи загрузчика.

Вот некоторые из немногих способов, которыми я все еще использую статические члены или классы:

• [ThreadStatic] static поля, используемые в классах, которые должны обеспечивать поведение одиночного потока
• статические конструкторы в моих классах конфигурации .NET, такие как ConfigurationSection, ConfigurationElement и т. Д.
  • Я начал заменять этот стиль конструирования класса конфигурации на простое использование атрибутов [ConfigurationProperty()], которое проще и в целом чище, хотя и требует очень небольших дополнительных затрат
• Действительно глобальные, совместно используемые данные времени выполнения ... это просто проще, чем использование IoC и дополнительный тип