Diversi modelli per una entità

Il tuo problema è molto comune tra le applicazioni che non sono minuscole. Prima o poi potresti iniziare a richiedere rappresentazioni diverse della stessa entità, per qualsiasi motivo, che si tratti di prestazioni o semplicemente di soddisfare meglio il tuo livello di business logic.

Avere modelli diversi per una singola entità non è una cattiva idea, se è questo che risolve il problema.

Di solito implemento uno spesso strato CUD (Crea, Aggiorna, Elimina) per convalidare correttamente le mie entità, questo spesso strato consiste nella convalida delle regole aziendali, delle proprietà dell'oggetto, delle relazioni, ma se un oggetto supera l'intero livello di scrittura allora sono sono sicuro che il modello sia valido. Con questo in mente, quindi, utilizzo un livello molto sottile per le letture che è molto veloce, perché è ridotto a zero di tutte le trasformazioni che sarebbero state altrimenti necessarie.

Per rendere le applicazioni più flessibili possibile senza implementare un sovraccarico, mi piace atomizzare le mie query di lettura in modo che restituiscano solo le chiavi primarie delle entità e quindi utilizzino un altro livello, puoi chiamarlo ModelCreators , che ha metodi accettare id dal livello atomizzato e usare quei modelli di costrutti.

In pratica, potrebbe essere simile a questo:

package Users.Devices.Atomized;

// pseudo-Java code
final class UsersDevicesQuery {

    public List<int> findDevicesForUser(final int userId) {
        // logic to filter out ids of user's devices
    }
}

package Users.Devices.ModelCreators;

final class WithPushTokenQuery {

    public List<WithPushToken> loadModels(final List<int> ids) {
        // logic to return models
    }
}

Questo approccio mi ha dimostrato di essere abbastanza buono, perché mantiene classi e metodi molto coesi e tuttavia molto dinamici - se decidi di cambiare la struttura del tuo modello puoi farlo senza toccare la logica di query e / o se vuoi per cambiare la logica di interrogazione è possibile farlo senza alterare le classi utilizzate per costruire i modelli.

È un'ottima decisione dividere in più classi (modelli). In Domain Driven Design devi fare questo: in ogni Contesto Limitato esiste un modello diverso (classe se vuoi), anche se si sovrappongono un po '.

Inoltre, in CQRS, dividi persino il lato Scrittura dal lato Lettura in modelli Write (Command) e Read (Query). In questo modo i tuoi modelli diventano più chiari / puliti e puoi ottimizzare quasi all'infinito il lato di lettura dell'applicazione.

Come altri hanno già detto, MVC non è adatto per la modellazione di domini complessi, in quanto si tratta più di un'architettura dell'interfaccia utente.