Se il modello in MVC ha più scopi (viste), dovrebbe essere diviso in più modelli?

Question

Se il modello in MVC ha più scopi (viste), dovrebbe essere diviso in più modelli?

#1 da (2 voti)
#2 da (1 voti)

0

In MVC (sto usando Spring, anche se non è rilevante per la discussione) ho un modello seguente:

public class User {
    private Long userId;
    private String username;
    private String password;
    private String passwordRepeat;
    private String email;
    private boolean rememberLogin;
    /// ctors, setters and getters [...]
}

Questo modello viene utilizzato durante la registrazione e il login e quindi contiene una somma di campi per entrambi gli scopi. In particolare - passwordRepeat non è completamente rilevante durante il login e viceversa - rememberLogin non è utilizzato durante la registrazione. Tutto andava bene fino a quando ho iniziato ad aggiungere la validazione (javax.validation) come annotazione ai campi. Ad esempio voglio mettere i vincoli su passwordRepeat in modo che non sia nullo e con un determinato intervallo di dimensioni, tuttavia sarà inevitabilmente nullo durante la convalida dell'accesso.

Un modello come questo che serve a molteplici scopi può essere suddiviso in più oggetti (ad esempio: UserLoginData, UserRegistrationData e User) o esiste un modo migliore per avvicinarsi a questo?

design-patterns mvc

posta Jacek Ślimok 14.08.2017 - 18:17

fonte

2 risposte

2

Dividili. Mantenerli insieme viola il principio della responsabilità unica, che, in parole povere, è che una classe dovrebbe avere una ragione per cambiare. Se questo modello serve sia la pagina di registro che la pagina di accesso, sta facendo troppo. Se la pagina di accesso cambia, perché la pagina di registro dovrebbe esserne potenzialmente influenzata? Non dovrebbe. Strettamente collega il registro e le pagine di accesso in modo non ovvio.

Questo potrebbe non sembrare un grosso problema per le pagine di registrazione e di accesso, ma per quanto riguarda le altre pagine? Si sarà davvero tentati di riutilizzare un modello solo perché capita di avere tutti i campi necessari piuttosto che scrivere una nuova classe di modelli. E poi alla fine si finisce con la classe GodModel che contiene le proprietà per tutto ciò che nel sistema. Non hai mai bisogno di scrivere un altro modello, ma il cielo ti aiuta a provare ad usarlo.

risposta data 14.08.2017 - 22:39

fonte

Leggi altre domande sui tag design-patterns mvc

Interfacce mobili ma non classi concrete Su una connessione crittografata, le destinazioni dei pacchetti sono visibili a una terza parte?

score 1 · Accepted Answer

Ci sono essenzialmente due approcci per questo genere di cose.

Approccio n. 1. Modello singolo

Scrivi un modello singolo, User e diverse azioni che lo accompagnano, ad es. Add , Edit , Delete , List e View . Tutte le viste utilizzerebbero lo stesso modello (o forse un List<model> . Questo tipo di approccio è quello che ottieni quando usi le procedure guidate dello scaffolding in Visual Studio ed è OK per le operazioni CRUD di base senza alcuna peculiarità.

Approccio n. 2. Visualizza modello

Con questo approccio, scrivi un modello specifico per la vista. Quando si esegue questa operazione, è possibile fare riferimento al modello come ViewModel . In generale, il modello in questo tipo di design agisce come un contenitore per un'azione, non un'entità; puoi considerarlo come l'equivalente di un modulo cartaceo che una persona riempirebbe quando formalmente facendo una richiesta di qualche business unit.

Quindi dovresti chiederti, è l'atto di registrare come un utente più simile all'azione CRUD di "Aggiungi utente dominio utente", o è più simile a "Crea e invia una richiesta di registrazione"?

Nella mia esperienza, se un utente si registra per utilizzare un sito Web per la prima volta, è più come una richiesta che un'azione CRUD, e dovrebbe ottenere il proprio ViewModel. Se l'utente è già registrato, ma forse sta impostando i subuser (cioè le persone con accesso condiviso), è più simile a un'operazione CRUD e forse potresti ottenere una singola classe del modello.