¿Es este un modelo de dominio anémico?

Question

Estoy tratando de construir mi primera aplicación Crud, y no entiendo si debería usar un objeto que contenga getters y setters separados.

Considerando que tenemos el Tutorial de inicio rápido de Zend Framework con una estructura de modelo que contiene:

• Puerta
• Datamapper
• Objeto de dominio (clase de modelo)

Si el objeto de dominio (como se presenta en el tutorial de inicio rápido de Zend) consiste solo en Getters y Setters, ¿es un antipatrón? En cierto sentido, ¿estamos dividiendo innecesariamente el objeto de dominio con un script de transacción?

Por favor avise.

Answer 1

Los objetos de dominio se separan de la lógica comercial del software. Esta es una idea importante de programación de procedimiento.

Sin embargo, este patrón es considerado un candidato para un antipatrón por parte de algunos desarrolladores, lo que significa que podría ser una práctica ineficaz.

De hecho, podría considerar las desventajas

• Su modelo es menos expresivo, los captadores y los setters no son realmente buenos para describir el modelo.
• El código es más difícil de reutilizar, obtienes código dublicado entre tus scripts transaccionales
• Tienes que usar envoltorios que ocultan la estructura de datos real (por lo que tal vez no realmente OOP)
• Siempre hay un acceso global a entidades

Creo que el punto más interesante a considerar es que los objetos del modelo de dominio no pueden asegurar su corrección en ningún momento. Porque su mutación tiene lugar en capas separadas.

También trabajé en una aplicación Crud con Zend Framework. La clara separación entre la lógica y los datos es realmente excelente, pero cuando progresas te das cuenta de que la cantidad de capas y mapeadores se vuelve cada vez más grande. Intente reutilizar su código tanto como pueda y evite la dublicación.

Answer 2

El modelo de dominio anémico es un anti-paterna solo si está tratando de construir un modelo de dominio real (también también conocido como modelo de dominio del diseño impulsado por el dominio) y termina con entidades con solo estado y sin comportamiento.

Para una aplicación CRUD simple, un modelo de dominio anémico es probablemente una mejor práctica, especialmente cuando tiene un marco que hace que su trabajo sea muy fácil.

Ver el artículo de Martin Fowler sobre Modelo de dominio anémico y también Artículo de Greg Young.