asp.net - qué - ¿Cuáles son las desventajas de los métodos estáticos?

static programacion

Question

¿Cuáles son las desventajas de usar métodos estáticos en una capa de negocio del sitio web versus instanciar una clase y luego llamar a un método en la clase? ¿Cuáles son los éxitos de rendimiento en ambos sentidos?

Answer 1

1. Testabilidad: las dependencias estáticas son menos comprobables
2. Enhebrado: puede tener problemas de concurrencia
3. Diseño: las variables estáticas son como variables globales

Answer 2

En cuanto al rendimiento, el uso de métodos estáticos evita la sobrecarga de la creación / destrucción de objetos. Esto usualmente no es significativo.

Deben usarse solo cuando la acción que realiza el método no está relacionada con el estado, por ejemplo, para los métodos de fábrica. No tendría sentido crear una instancia de objeto solo para crear una instancia de otro objeto :-)

String.Format (), los métodos TryParse () y Parse () son buenos ejemplos de cuando un método estático tiene sentido. Realizan siempre lo mismo, no necesitan estado y son bastante comunes, por lo que tener instancias tiene menos sentido.

Por otro lado, usarlos cuando no tiene sentido (por ejemplo, tener que pasar todo el estado al método, digamos, con 10 argumentos), hace que todo sea más complicado, menos fácil de mantener, menos legible y menos comprobable, como dice Jon. . Creo que no es relevante si se trata de una capa de negocios o en cualquier otro lugar del código, solo utilícelos con moderación y cuando la situación lo justifique.

Answer 3

Jon Skeet tiene razón, la diferencia de rendimiento sería insignificante ...

Habiendo dicho eso, si está construyendo una aplicación empresarial, sugeriría usar el enfoque tradicional escalonado adoptado por Microsoft y otras compañías de software. Permítanme explicar brevemente:

Voy a utilizar ASP.NET porque estoy más familiarizado con él, pero esto debería traducirse fácilmente en cualquier otra tecnología que pueda estar utilizando.

La capa de presentación de su aplicación estaría compuesta por páginas ASP.NET aspx para visualización y códigos subyacentes ASP.NET para "control de procesos". Esta es una forma elegante de hablar sobre lo que sucede cuando hago clic en enviar. ¿Voy a otra página? ¿Hay validación? ¿Debo guardar información en la base de datos? ¿A dónde voy después de eso?

El control del proceso es el enlace entre la capa de presentación y la capa empresarial. Esta capa se divide en dos partes (y aquí es donde entra su pregunta). La forma más flexible de crear esta capa es tener un conjunto de clases de lógica de negocios (por ejemplo, Proceso de pago, Gestión de clientes, etc.) que tengan métodos como Pago por proceso, Cliente eliminar, Crear cuenta, etc. Estos serían métodos estáticos.

Cuando los métodos anteriores son llamados desde la capa de control del proceso, manejan toda la creación de instancias de los objetos comerciales (por ejemplo, Cliente, Factura, Pago, etc.) y aplican las reglas comerciales apropiadas.

Sus objetos comerciales son los que manejarían toda la interacción de la base de datos con su capa de datos. Es decir, saben cómo guardar los datos que contienen ... esto es similar al patrón MVC.

Entonces, ¿cuál es el beneficio de esto? Bueno, todavía tienes la capacidad de prueba en múltiples niveles. Puede probar su UI, puede probar el proceso de negocio (llamando a las clases de lógica de negocios con los datos apropiados) y puede probar los objetos de negocio (instanciando manualmente y probando sus métodos. También lo sabe si su modelo de datos) o los objetos cambian, su UI no se verá afectada, y solo las clases de lógica de negocio tendrán que cambiar. Además, si la lógica de negocios cambia, puede cambiar esas clases sin afectar los objetos.

Espero que esto ayude un poco.

Answer 4

Las diferencias de rendimiento serán insignificantes.

La desventaja de usar un método estático es que se vuelve menos comprobable. Cuando las dependencias se expresan en llamadas a métodos estáticos, no puede reemplazar esas dependencias con mocks / stubs. Si todas las dependencias se expresan como interfaces, donde la implementación pasa al componente, entonces puede usar una versión de prueba / simulación del componente para las pruebas unitarias, y luego la implementación real (posiblemente conectada con un contenedor IoC) para el real despliegue.

Answer 5

Si el método utiliza datos estáticos, esto realmente se compartirá entre todos los usuarios de su aplicación web.

Solo código, no hay problemas reales más allá de los problemas habituales con los métodos estáticos en todos los sistemas.