Когда лучше всего использовать статические функции в ASP.NET? - PullRequest
Новая
       10

Когда лучше всего использовать статические функции в ASP.NET?

5 голосов
/ 02 ноября 2009

Мне было интересно, когда использовать статические функции, а когда нет в ASP.NET?

Каковы преимущества и недостатки их использования в различных аспектах, таких как производительность, следование передовой практике и т. Д. (И многое другое, в зависимости от того, что вы считаете уместным).

Ответы [ 3 ]

4 голосов
/ 02 ноября 2009

Минусы:

  • проблемы с потоками (статические функции не требуют вызова экземпляра, поэтому их легко вызывать из разных частей кода, и если они читают / пишут в общее состояние, это состояние может быть повреждено в мульти многопоточная среда, такая как ASP.NET)
  • сложный для модульного тестирования (поскольку статические функции не требуют экземпляра объекта, внедрение конструктора невозможно, что означает, что единственный способ внедрить зависимости - это передать их в качестве аргументов самой функции)

Плюсы:

  • производительность (это сомнительно - в большинстве случаев прирост производительности будет совершенно незначительным по сравнению с другими частями кода)
2 голосов
/ 02 ноября 2009

Определенно существуют ситуации, когда статическое является подходящим решением, как и в любом приложении. Каждый раз, когда у вас есть какой-то объект, который должен жить в области приложения, а не в области запроса, он должен быть статическим, и вы должны использовать статические методы для доступа к нему и манипулирования им.

В качестве примера приведу фрагмент кода, который я недавно написал для приложения ASP.NET, которое по сути является кешем сериализатора. Сериализаторы дороги в создании, и мы можем повторно использовать один и тот же тип для каждого типа в течение всего срока службы нашего приложения, поэтому нет необходимости тратить время в каждом потоке запросов на них:

( Примечание: это было урезано, чтобы продемонстрировать статические аспекты) 

public class XmlSerializerUtility
{
    private static Dictionary<Type, XmlSerializer> serializers = new Dictionary<Type, XmlSerializer>();
    private static object sync = new object();

    public static T Deserialize<T>(string input)
    {
       XmlSerializer xs = GetSerializer(typeof(T));
        using (StringReader sr = new StringReader(input))
        {
            return (T)xs.Deserialize(sr);
        }
    }

    public static XmlDocument Serialize(object input)
    {
        XmlDocument doc = new XmlDocument();
        XmlSerializer xs = GetSerializer(input.GetType());
        using (MemoryStream stream = new MemoryStream())
        {
            xs.Serialize(stream, input);
            stream.Position = 0;
            doc.Load(stream);
        }
        return doc;
    }

    private static XmlSerializer GetSerializer(Type type)
    {
        lock (sync)
        {
            XmlSerializer xs = null;
            if (!serializers.ContainsKey(type))
            {
                xs = new XmlSerializer(type);
                serializers.Add(type, xs);
            }
            else
            {
                xs = serializers[type];
            }
            return xs;
        }
    }
}
1 голос
/ 02 ноября 2009

Единственным существенным недостатком статического метода является то, что он почти полностью не тестируется на единицу. Пользователи метода должны привязываться к конкретному методу и не могут привязываться к абстракции, что затрудняет подделку или издевательство, если не невозможно.

Однако это может быть или не быть проблемой, в зависимости от кода.

Еще одна вещь, которую вы должны остерегаться, это то, что статические данные универсальны для всех запросов к серверу.

...