Spring MVC 3 - Associazione di un oggetto "immutabile" a un modulo

Question

Ho diverse classi di DDD ricche di unità accuratamente testate e finemente lavorate, con invarianti immutabili finali e verifiche di integrità. L'istanziazione dell'oggetto avviene tramite costruttori adeguati, metodi di factory statici e persino tramite Builder.

Ora, devo fornire un modulo Spring MVC per creare nuove istanze di alcune classi.

Mi sembra (non sono un esperto) che devo fornire costruttore vuoto e setter di attributi per le classi di supporto di tutte le forme che voglio associare.

Quindi, cosa dovrei fare?

Creare oggetti anemici dedicati al backing modulo e trasferire le informazioni al mio modello di dominio (così tanto per il principio DRY ...) chiamando i metodi/builder appropriati?

Oppure c'è un mecanismo che mi è mancato e che può salvare la mia giornata? :)

Grazie in anticipo per la tua saggezza!

Answer 1

Sì, sarà necessario creare oggetti per il modulo per prendere tutto l'input e aggiornare il modello con questi oggetti in un'unica operazione.

Ma non chiamerò questo oggetto anemico (specialmente se fai DDD). Questi oggetti rappresentano un'unità di lavoro. Quindi anche questi sono concetti di dominio!

Answer 2

Gli oggetti utilizzati per il binding con i livelli di presentazione sono normalmente chiamati modelli di visualizzazione e sono DTOs finalizzati alla visualizzazione di dati mappati da oggetti di dominio e quindi alla mappatura di input dell'utente in oggetti di dominio. Visualizza i modelli in genere sono molto simili agli oggetti di dominio che rappresentano tuttavia ci sono alcune importanti differenze:

1. dati dagli oggetti del dominio può essere appiattita o comunque trasformato per soddisfare le esigenze di un determinato punto di vista. Avere la mappatura in oggetti semplici è più facile da gestire rispetto ai mapping nel framework di presentazione, come ad esempio MVC. È più facile eseguire il debug e rilevare gli errori.

2. Una determinata vista può richiedere dati da più oggetti di dominio: potrebbe non esserci un singolo oggetto dominio che soddisfa i requisiti di una vista. Un modello di visualizzazione può essere popolato da più oggetti di dominio.

3. Un modello di vista è normalmente progettato tenendo conto di un framework di presentazione specifico e come tale può utilizzare attributi specifici del framework per il binding e la convalida del lato client. Come hai affermato, un requisito tipico è per un costruttore senza parametri, che va bene per un modello di vista. Di nuovo, è molto più facile testare e gestire un modello di visualizzazione piuttosto che una sorta di meccanismo di mappatura complesso.

Visualizza modelli sembrano violare il principio DRY, ma dopo uno sguardo più attento la responsabilità del modello di vista è diverso, quindi con la single responsibility principle a mente che è opportuno avere due classi. Inoltre, dai un'occhiata all'articolo this discutendo l'errore del riutilizzo, spesso guidato dal principio DRY.

Inoltre, i modelli di vista sono anemici, sebbene possano avere un costruttore che accetta un oggetto dominio come parametro e un metodo per creare e aggiornare un oggetto dominio utilizzando i valori nel modello di vista come input.Dall'esperienza, trovo che sia una buona pratica creare una classe del modello di vista per ogni entità di dominio che sarà resa dal livello di presentazione. È più semplice gestire la gerarchia di classi doppie degli oggetti dominio e dei modelli di visualizzazione piuttosto che gestire meccanismi di mappatura complessi.

Nota anche, ci sono librerie che tentano di semplificare la mappatura tra modelli di viste e oggetti di dominio, ad esempio AutoMapper per .NET Framework.

Answer 3

Ho risolto questo con la creazione di un'interfaccia 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 
} 

Questo impedisce anche vista la convalida e la formattazione roba da perdite nel modello di dominio. Non mi piace avere annotazioni specifiche di Spring (o altre specifiche del framework) (@Value, ecc.) E javax.validation nei miei oggetti di dominio.