¿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?¿Cuáles son las desventajas de los métodos estáticos?
Las diferencias de rendimiento serán insignificantes.
La desventaja de utilizar 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.
Si el método utiliza datos estáticos, esto realmente se compartirá entre todos los usuarios de su aplicación web.
Sólo código, no hay problemas reales más allá de los problemas habituales con los métodos estáticos en todos los sistemas.
Jon Skeet es correcto - la diferencia de rendimiento sería insignificante ...
Dicho esto, si usted está construyendo una aplicación empresarial, se recomienda usar el enfoque secuencial tradicional expuesta por Microsoft y una serie de 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 de 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, PaymentProcessing, CustomerManagement, etc.) que tengan métodos como ProcessPayment, DeleteCustomer, CreateAccount, etc. Estos serían métodos estáticos.
Cuando los métodos anteriores se invocan desde la capa de control de procesos, manejan todas las instancias de 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 empresarial tendrán que cambiar. Además, si la lógica de negocios cambia, puede cambiar esas clases sin afectar a los objetos.
Espero que esto ayude un poco
Rendimiento sabio, el uso de métodos estáticos evita la sobrecarga de la creación/destrucción de objetos. Esto generalmente no es significativo.
Se deben usar 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 . Actúan siempre de la misma manera, no necesitan estado y son bastante comunes, por lo que las instancias tienen menos sentido.
Por otro lado, utilizarlos cuando no tiene sentido (por ejemplo, tener que pasar todo el estado en el 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.
"No tendría sentido crear una instancia de objeto solo para crear una instancia de otro objeto :-)" - lo hace si necesita decirle a alguien cómo crear instancias de un cierto tipo de una manera movible/conectable. Ese es el patrón de fábrica. –
Estoy hablando del patrón de método de fábrica allí ... –
depende. La clase estática System.Math no parece menos comprobable de lo que hubiera sido si no fuera estática. ¿Estoy equivocado, Jon? –
No es que el método estático en sí no sea comprobable; es que las cosas * que usan * métodos estáticos no son tan comprobables, porque no puede reemplazar la implementación del método estático por una simple. Por ejemplo, si el método llega a la base de datos, tu prueba también lo hará. –