¿Cuándo es mejor utilizar funciones estáticas en ASP.NET

Question

Me he estado preguntando, ¿Cuándo utilizar funciones estáticas y cuándo no en ASP.NET

¿Cuáles son las ventajas y desventajas en su uso, en varios aspectos como el rendimiento, siguiendo buenas prácticas, etc. (y muchas más, lo que creas que sea relevante).

Esperamos sus respuestas.

Gracias,
Mahesh Velaga.

Answer 1

Contras:

• problemas de threads (funciones estáticas no requieren una instancia para ser llamados, por lo que es fácil de invocar a ellos desde diferentes partes del código y si leen/escritura a una compartida declarar que este estado podría estar dañado en un entorno de subprocesos múltiples como ASP.NET)
• difícil de probar unitario (como las funciones estáticas no requieren una instancia de objeto, la inyección del constructor es imposible, lo que significa que la única forma de inyectar dependencias es pasándolos como argumentos para la función en sí)

Pros:

• de rendimiento (esto es cuestionable - en la mayoría de las ganancias de rendimiento casos serán completamente insignificante en comparación con otras partes del código)

Answer 2

La única desventaja importante a un método estático es que es casi completamente no verificable por unidad. Los usuarios del método deben vincularse al método concreto y no pueden vincularse a una abstracción, lo que dificulta o imposibilita la falsificación o burla.

Esto puede o no ser un problema, dependiendo del código, sin embargo.

La otra cosa que desea tener en cuenta es que los datos estáticos son universales en todas las solicitudes al servidor.

Answer 3

Definitivamente hay situaciones donde la solución estática es la solución adecuada, como con cualquier aplicación. Cada vez que tenga algún objeto que debería vivir en el ámbito de la aplicación, y no en el ámbito de solicitud, debe ser estático y debe usar métodos estáticos para acceder y manipularlo.

Como ejemplo, aquí hay un fragmento de código que escribí recientemente para una aplicación ASP.NET, que es esencialmente una memoria caché de serializador. Serializadores son caros para crear y podemos volver a utilizar la misma según el tipo durante el tiempo que la vida de la aplicación, así que no hay necesidad de perder tiempo en cada hilo solicitud de ellos:

(Nota: esto ha sido simplificada para demostrar los aspectos estáticos)

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; 
     } 
    } 
}