He estado jugando con el patrón de especificación para manejar y contener la lógica de negocio en nuestra aplicación C#/mvc. Hasta aquí todo bien. Sin embargo, tengo una pregunta: dado que crearemos una cantidad de objetos de especificación en el montón, ¿afectará esto el rendimiento de alguna manera en comparación con, por ejemplo, la creación de métodos de ayuda para manejar la lógica empresarial? ¡Gracias!Patrón de especificación y rendimiento
Tengo una pregunta, sin embargo, ya que vamos a crear una serie de objetos de especificación en el montón, ¿afectará el rendimiento de alguna manera frente a, digamos, crear métodos de ayuda para manejar la lógica comercial?
Por supuesto, afectará el rendimiento, cada línea de código que escriba y la elección de diseño que realice afecta el rendimiento de una manera u otra. Es poco probable que tenga sentido, sea un cuello de botella en su aplicación o valga la pena preocuparse, ya que es casi seguro que se trata de una optimización prematura. En estos días, debe centrarse en modelar su dominio de forma adecuada y escribir código extremadamente claro y fácil de mantener. Concéntrese más en la productividad del desarrollador que en la productividad de la máquina. Los ciclos de CPU son baratos y en un suministro casi ilimitado. Los ciclos de desarrollo no son baratos y no tienen un suministro ilimitado.
Pero solo usted puede saber si tendrá un impacto en el uso de su aplicación en el mundo real por perfiles. No sabemos ni podemos saberlo porque no conocemos su dominio, no conocemos a sus usuarios, no sabemos qué rendimiento espera, etc. E incluso si supiéramos esas cosas, todavía no podríamos hacerlo. Te daré una respuesta tan poderosa como puedes darte al desempolvar un generador de perfiles y ver lo que realmente hace tu aplicación.
Gracias y sí, estoy de acuerdo con sus comentarios sobre los muchos factores que influyen en el rendimiento. Como trato de contener nuestra lógica de negocios, encontré que el patrón de especificación es útil (lógica comercial resuable, prueba fácil para la unidad); sin embargo, nuestro liderazgo no está convencido y se puede lograr el mismo resultado con menos código y menos objetos usando helper métodos. – rh1200
ya que va a crear una serie de objetos de especificación en el montón, afectará eso el rendimiento de ninguna manera
La mayoría de los patrones de diseño de comercio fuera algo de sobrecarga para la limpieza de diseño - esto no es una excepción . En general, la cantidad de memoria que agregan las especificaciones es muy mínima (por lo general, un par de referencias, y eso es todo). Además, tienden a agregar un par de llamadas al método extra frente a la lógica personalizada.
Dicho esto, no trataría de optimizar esto prematuramente. La sobrecarga aquí es increíblemente pequeña, así que dudo mucho que sea notable en cualquier aplicación del mundo real.
¿Debería expresarse la preocupación sobre el recorrido del montón ya que las especificaciones podrían estar en el montón en cualquier orden y en cualquier número? – RBZ
Asignaciones de montón no son algo que temer en .NET, ya que a) compactación de montón significa que la asignación es generalmente bastante barata yb) recolección de basura significa que las asignaciones de montón son menos riesgosas (ya que no tienes que seguir la vida del objeto cuidadosamente.) –