java - modelo - programacion en 3 capas c#
¿Cuánta lógica de negocio deben contener los objetos Value? (6)
Un mentor que respeto sugiere que un simple frijol es una pérdida de tiempo, que los objetos de valor ''DEBEN'' contener cierta lógica comercial para ser útiles.
Otro dice que dicho código es difícil de mantener y que toda la lógica empresarial debe externalizarse.
Me doy cuenta de que esta pregunta es subjetiva. Preguntar de todos modos: quiero saber las respuestas desde más perspectivas.
Debería llamarlos objetos de transferencia o objetos de transferencia de datos (DTO) .
Anteriormente, este mismo patrón j2ee se llamaba ''Objeto de valor'' pero cambiaron el nombre porque se confundió con este
http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html
Para responder a su pregunta, solo pondría una lógica mínima a mis DTO, lógica que es necesaria por motivos de visualización.
Mejor aún, si hablamos de una aplicación web basada en una base de datos, iría más allá de los patrones core j2ee y usaría Hibernate o Java Persistence API para crear un modelo de dominio que admita la carga diferida de las relaciones y lo use en la vista.
Ver la sesión abierta a la vista .
De esta manera, no tiene que programar un conjunto de DTO y tiene toda la lógica de negocios disponible para usar en sus vistas / controladores, etc.
Depende.
Uy, ¿acabo de decir un cliché?
La pregunta básica para diseñar un objeto es: ¿será la lógica que gobierna los datos del objeto diferente o la misma cuando se usa / consume por otros objetos?
Si las diferentes áreas de uso requieren una lógica diferente, externalícela. Si es lo mismo, no importa a dónde viaje el objeto, colóquelo junto con la clase.
Estoy de acuerdo con Panagiotis: la sesión abierta en el patrón de vista es mucho mejor que el uso de DTO. Dicho de otra forma, he descubierto que una aplicación es mucho más simple si trafica con los objetos de su dominio (o algún compuesto de los mismos) desde su capa de vista hasta el final.
Dicho esto, es difícil de lograr, ya que tendrás que hacer que tu HttpSession coincida con la unidad de trabajo de tu capa de persistencia. Luego deberá asegurarse de que todas las modificaciones de la base de datos (es decir, crear, actualizar y eliminar) sean intencionales. En otras palabras, no desea que la capa de vista tenga un objeto de dominio, se modifique un campo y la modificación se mantenga sin que el código de la aplicación guarde el cambio intencionalmente. Otro problema importante de tratar es garantizar que su semántica transaccional sea satisfactoria. Por lo general, buscar y modificar un objeto de dominio se llevará a cabo en un contexto transaccional y no es difícil hacer que su capa ORM requiera una nueva transacción. Lo que es desafiante es una transacción anidada, en la que desea incluir un segundo contexto transaccional dentro del primero abierto.
Si no le importa investigar cómo una API que no es Java maneja estos problemas, vale la pena mirar el registro activo de Rails, que permite que las páginas del servidor de Ruby trabajen directamente con el modelo de dominio y atraviesen sus asociaciones.
La idea de juntar datos y lógica de negocios es promover la encapsulación y exponer el menor estado interno posible a otros objetos. De esta forma, los clientes pueden confiar en una interfaz en lugar de en una implementación. Ver el principio "Tell, Do not Ask" y la Ley de Demeter . La encapsulación facilita la comprensión de los estados en los que se encuentran los datos, la facilidad de lectura del código, la facilidad para desacoplar clases y, en general, la prueba de unidad más sencilla.
La externalización de la lógica de negocios (generalmente en clases de "Servicio" o "Gerente") hace preguntas como "¿dónde se utilizan estos datos?" y "¿En qué estados puede estar?" mucho más difícil de responder. También es una forma de pensar procesal, envuelta en un objeto. Esto puede conducir a un modelo de dominio anémico .
El comportamiento de externalización no siempre es malo. Por ejemplo, una capa de servicio puede orquestar objetos de dominio, pero sin asumir sus responsabilidades de manipulación de estado. O bien, cuando en su mayoría realiza lecturas / escrituras en un DB que se correlaciona bien con los formularios de entrada, tal vez no necesite un modelo de dominio, o el objeto doloroso / la sobrecarga de mapeo relacional que conlleva, en absoluto.
Los objetos de transferencia a menudo sirven para desacoplar capas de arquitectura entre sí (o desde un sistema externo) al proporcionar la información de estado mínima que necesita la capa de llamada, sin exponer ninguna lógica comercial.
Esto puede ser útil, por ejemplo, al preparar información para la vista: simplemente déle a la vista la información que necesita, y nada más, para que pueda concentrarse en cómo mostrar la información, en lugar de qué información mostrar. Por ejemplo, el TO puede ser una agregación de varias fuentes de datos.
Una ventaja es que sus vistas y sus objetos de dominio están desacoplados. El uso de objetos de dominio en JSP puede hacer que su dominio sea más difícil de refactorizar y promueve el uso indiscriminado de getters y setters (por lo tanto, rompe la encapsulación).
Sin embargo, también hay una sobrecarga asociada con tener muchos objetos de transferencia y, a menudo, mucha duplicación. Algunos proyectos en los que he estado terminan con TO que básicamente reflejan otros objetos de dominio (que considero un antipatrón).
Lo que dijo Korros.
Objeto de valor: = Un pequeño objeto simple, como dinero o un rango de fechas, cuya igualdad no se basa en la identidad.
DTO: = Un objeto que transporta datos entre procesos para reducir el número de llamadas a métodos.
Estas son las definiciones propuestas por Martin Fowler y me gustaría popularizarlas.
Mi preferencia personal es poner toda la lógica comercial en el modelo de dominio en sí, es decir en los objetos de dominio "verdaderos". Entonces, cuando se crean Objetos de Transferencia de Datos, en su mayoría son solo una representación de estado (inmutable) de los objetos de dominio y, por lo tanto, no contienen lógica de negocios. Sin embargo, pueden contener métodos para clonar y comparar, pero la esencia del código de lógica de negocios permanece en los objetos del dominio.