Dónde poner el estado de la aplicación?

Question

¿Dónde en el código debo colocar la creación de objeto (objetos con estado) y dónde no? En que capas?

Por ejemplo, una vez puse una referencia de objeto dentro de una clase Hibernate DAO y me dijeron que esto era incorrecto porque no se supone que las clases DAO tengan estado. El estado debe estar dentro de la 'capa de servicio'.

Me han dicho que no debería crear objetos nuevos en llamadas recurrentes a métodos como UpdateCart(). La creación de objetos es costosa y no debe figurar en su código en todas partes. Debería estar sentado solo en los métodos de tipo de inicialización. Por ejemplo, si una aplicación de comercio electrónico necesita un carro, colóquelo en la sesión. Si necesita algún objeto principal general, póngalo en el código de inicialización. Créelo una vez allí y deje que el resto de la aplicación acceda a su instancia más adelante. No crees esta instancia en cada llamada.

Estoy confundido acerca de este principio de diseño. Lo más extraño que escuché es que 'una aplicación no debería tener estado'. El estado debe mantenerse en la capa de datos donde está la base de datos '. De Verdad? Soy bastante nuevo en estos conceptos de diseño y no sé dónde buscar para obtener más información sobre él. GoF? Diseño de patrones de libros? El objetivo es crear código cualitativo (es decir, para ser utilizado en el negocio).

Gracias

Answer 1

¿Qué es una buena práctica puede variar base de don el tipo de proyecto que es.

Para la mayoría de los proyectos, crear objetos no es tan caro para la CPU. Un costo que no siempre se articula bien es el costo para el diseño. Parece que su aplicación tiene una metodología de diseño donde todos los estados y objetos necesitan ser gestionados de forma controlada y centralizada. Esto se hace a menudo para mejorar el mantenimiento y simplificar el diseño. No asumiría que solo debiera saber de qué se trata el diseño a menos que se lo haya explicado muy claramente.

Sospecho que el resto del equipo está acostumbrado a trabajar de una manera particular y no creo que deban documentar o enseñarle esta metodología, solo decirle cuándo lo "equivocó". Esto no es productivo en mi humilde opinión, pero tiene que lidiar con la situación que tiene y hacerles preguntas cuando se trata de la ubicación de las estructuras estatales o de datos.

Answer 2

'se supone que una aplicación no tiene estado. Estado debe mantenerse en la capa de datos en la base de datos es

Hay diseños en los que esta es la norma, llamado acertadamente 'arquitecturas sin estado. Si toda arquitectura debe ser apátrida es, por supuesto, dudosa y el mismo término quizás también se abre al debate.

La mayoría de las aplicaciones "sin estado" de hecho tienen estado, pero como la regla anterior establece (sin juego de palabras) este estado se mantiene en un lugar global; la base de datos. Como menciona Peter, las razones para esto podrían ser la facilidad de mantenimiento y la simplificación, pero a menudo también se escucha que esto es para scalability. Si el estado no aparece en ninguna otra parte sino en la base de datos, se cree que es fácil agregar servidores de aplicaciones para el usuario adicionales, servidores de procesamiento y lo que sea.

Si bien esto tiene cierto mérito, creo que sí tenemos que hacer una distinción entre estado temporal y estado autoritario.

El estado temporal puede ser algo así como el lugar en el que se encuentra en un proceso de pedido y los detalles que ya ha introducido. En Java EE, puede mantener esto en, por ejemplo, @ConversationScoped beans, o @Stateful beans.Esto es, por lo tanto, un estado que usted debe mantener dentro de la capa web resp. capa de negocios.

Las ventajas de esto son la facilidad de uso, el rendimiento y la descarga de la base de datos central única. Claro, también puede almacenar el estado temporal en su base de datos central, pero es probable que desee mantenerlo alejado de los datos regulares no temporales, lo que significa que se necesita una complejidad de programación adicional. También suele ser mucho más rápido recuperar datos de la capa web, y elimina algo de carga de la base de datos.

En muchos sistemas sólo hay una única base de datos maestra (una base de datos de aceptar escrituras), por lo que esta sola base de datos podría convertirse en un gran cuello de botella en la que la configuración.

Dependiendo de su arquitectura real y configuración, no manteniendo el estado temporal en la base de datos -puede en realidad mejorar su capacidad de escala.

Las desventajas son que no necesita el cliente para que se adhieren a un único servidor en el que se mantiene actualmente el estado temporal. Esto es típico llamado 'sesiones adhesivas'. Si el servidor con el que este cliente interactúa falla o necesita reiniciarse o lo que sea, el cliente perderá estos datos temporales. Existen algunos esquemas como el estado de replicación en todos los nodos de un clúster o en nodos cercanos (replicación de amigos), pero esto complica las cosas nuevamente y puede sobrecargar la red (si todos los nodos se replican constantemente entre sí).

Estado autorizado significa que representa los datos compartidos que es la única fuente de información. Este tipo de estado es algo que casi siempre nos gusta tener en una ubicación central, pero a veces se ve que se almacena en, p. Ej. un nodo web.

Por ejemplo, supongamos que tenemos una lista de precios de los últimos, y en lugar de persistir esta a una ubicación central que mantenerlo en el nodo web en la que se ha introducido. Ahora hay un concepto del nodo web "uno y solo" que tiene esta información y otros servidores pueden comenzar asumiendo que solo existe este nodo web "único". Agregar nodos adicionales ahora es imposible, ya que rompe esta suposición.