Spring MVC 3 - Encuadernación de un objeto 'inmutable' a un formulario

Question

Tengo varias clases de modelos ricos en DDD completamente probadas y elaboradas a mano, con invariantes inmutables finales y comprobaciones de integridad. La instanciación del objeto ocurre a través de constructores adecuados, métodos de fábrica estáticos e incluso a través de constructores.

Ahora, tengo que proporcionar un formulario Spring MVC para crear nuevas instancias de algunas clases.

Me parece (no soy un experto) que tengo que proporcionar constructores de atributos y constructores vacíos para todas las clases de respaldo de formularios que quiero vincular.

Entonces, ¿qué debo hacer?

Crear objetos anémicos dedicados a formar el respaldo y transferir la información a mi modelo de dominio (tanto para el principio DRY ...) llamando al método/constructor apropiado?

¿O hay algún mecanismo que eché de menos que pueda salvar mi día? :)

¡Gracias de antemano por su sabiduría!

Answer 1

Sí, tendrá que crear Objetos para que el formulario tome todas las entradas, y actualice su modelo con estos objetos en una sola operación.

Pero no llamaré anémico a estos objetos (especialmente si haces DDD). Estos objetos representan una unidad de trabajo. ¡Así que estos también son Conceptos de Dominio!

Answer 2

Los objetos que se utilizan para enlazar con las capas de presentación normalmente se denominan modelos de vista y son DTOs destinados a mostrar los datos asignados desde objetos de dominio y luego asignar la entrada del usuario a objetos de dominio. Ver modelos normalmente son muy similares a los objetos de dominio que representan sin embargo, hay algunas diferencias importantes:

1. Los datos de los objetos de dominio puede ser aplanado o se transforma de otro modo para adaptarse a los requisitos de una vista determinada. Tener la asignación en objetos simples es más fácil de administrar que las asignaciones en el marco de presentación, como MVC. Es más fácil depurar y detectar errores.

2. Una vista determinada puede requerir datos de varios objetos de dominio; es posible que no haya un solo objeto de dominio que se ajuste a los requisitos de una vista. Un modelo de vista puede ser poblado por múltiples objetos de dominio.

3. Un modelo de vista normalmente se diseña con un marco de presentación específico en mente y, como tal, puede utilizar atributos específicos del marco para la validación del enlace y del lado del cliente. Como dijiste, un requisito típico es para un constructor sin parámetros, lo cual está bien para un modelo de vista. Nuevamente, es mucho más fácil probar y administrar un modelo de vista que algún tipo de mecanismo de mapeo complejo.

Ver modelos parecen violar el principio DRY, sin embargo después de una mirada más cercana a cargo del modelo de vista es diferente, por lo que con el single responsibility principle en cuenta que es apropiado tener dos clases. Además, eche un vistazo al artículo this que discute la falacia de la reutilización a menudo dirigida por el principio DRY.

Además, los modelos de vista son anémicos, aunque pueden tener un constructor aceptando un objeto de dominio como parámetro y un método para crear y actualizar un objeto de dominio usando los valores en el modelo de vista como entrada.Por experiencia, creo que es una buena práctica crear una clase de modelo de vista para cada entidad de dominio que la capa de presentación representará. Es más fácil administrar la jerarquía de clases dobles de los objetos de dominio y los modelos de visualización que gestionar los mecanismos de mapeo complejos.

Tenga en cuenta también que hay bibliotecas que intentan simplificar la asignación entre modelos de vista y objetos de dominio, por ejemplo AutoMapper para .NET Framework.

Answer 3

Solucioné esto mediante la creación de una interfaz DTO:

public interface DTO<T> { 
    T getDomainObject(); 

    void loadFromDomainObject(T domainObject); 
} 

public class PersonDTO implements DTO<Person> { 
    private String firstName; 
    private String lastName; 

    public PersonDTO() { 
     super(); 
    } 

    // setters, getters ... 

    @Override 
    public Person getDomainObject() { 
     return new Person(firstName, lastName); 
    } 

    @Override 
    public void loadFromDomainObject(Person person) { 
     this.firstName = person.getFirstName(); 
     this.lastName = person.getLastName(); 
    } 

    // validation methods, view formatting methods, etc 
} 

Esto también se detiene vista validación y cosas formato de fugas en el modelo de dominio. Realmente no me gusta tener anotaciones específicas de Spring (u otras específicas del framework) (@Value, etc) y anotaciones javax.validation en mis objetos de dominio.