Un modello MVP / MVC dovrebbe contenere un comportamento?

1

Ho letto molte domande qui, che sembrano confondere il modello MVP / MVC con il modello di dominio. Nella mia mente, il modello MVP chiama il servizio, che quindi chiama un ricco modello di dominio in cui il modello MVC / MVP è un modello di vista.

Ho visto molto codice, che fa questo (questo è il modello MVC):

public class Model : IModel
    {
        private IService service;

        public PersonModel GetPerson(int id)
        {
            PersonDTO personDTO = service.GetPerson(int id);
            PersonModel personModel = Mapper.Map<PersonModel>(personDTO);
            return personModel;
        }
    }

Il modello chiama il servizio e il servizio chiama un modello di dominio ricco, cioè un modello di dominio in cui le classi contengono sia lo stato che il comportamento.

Si noti nel codice precedente che esiste una classe chiamata Modello (che contiene il comportamento e chiama il servizio) e una classe chiamata PersonModel. Dovrebbe esserci una classe chiamata PersonModel, che contiene sia lo stato che il comportamento se un modello di dominio ricco è a livello di livello aziendale / dominio? Sto parlando delle migliori pratiche qui. So che entrambi gli approcci funzionano.

    
posta w0051977 07.06.2017 - 10:25
fonte

4 risposte

1

No. Il controller o il relatore dovrebbe idealmente contenere tutto il tuo comportamento.

Lo scopo dell'utilizzo di un framework MVC / MVP è di separare codice / dati in un modello (tipicamente il tuo database), una vista (con cui l'utente interagirà) e un controller / relatore, che è il tuo mezzo uomo tra il modello e la vista. Se uno sviluppatore dovesse unirsi al tuo team, guarderebbe immediatamente al controller / presentatore se il cambiamento di comportamento è il risultato desiderato.

È possibile, naturalmente, aggiungere comportamenti nella vista. È solo inutile e porterà a complicazioni lungo la linea, quindi dico di evitarlo.

    
risposta data 07.06.2017 - 19:09
fonte
0

Da una prospettiva di mvc le due classi separate nel tuo esempio sono desiderabili su una singola classe. Ciò ti consente di separare correttamente le preoccupazioni che aiutano a mantenere più facilmente il tuo codice. Se il tuo PersonModel conteneva il servizio in esso, lo esponesti alla vista che è contro il pattern mvc, se avesse un servizio non funzionante, quindi stai isolando la vista dall'accesso ai dati, quindi hai un oggetto parzialmente funzionante che è probabilmente peggiore e causerà mal di testa. Inoltre, avendo le classi separate fornite a PersonModel solo una ragione per cambiare, che è ciò che una persona è cambiata. Anche il servizio non è influenzato da modifiche a ciò che una persona è interessata solo a come ottenere quella persona. Mantenere questa separazione ti aiuta a evitare che il tuo livello aziendale passi attraverso il tuo modello e duplichi la logica o li accoppi al punto in cui non possono più essere separati in modo pulito.

    
risposta data 07.06.2017 - 14:14
fonte
0

MVP e amp; MVC sono schemi di progettazione dell'interfaccia utente Non vedo come la logica di business si possa posizionare ovunque all'interno dei suoi limiti.

IMO il modello in questi modelli sono semplicemente i modelli di vista che contengono i dati visualizzati dalla vista. Il presentatore / controller interrogherà i servizi / i modelli di dominio e popolerà il modello di visualizzazione con il risultato di queste query.

    
risposta data 07.06.2017 - 15:12
fonte
0

Indipendentemente dal modello, dovremmo tenere presente che i modelli di progettazione sono uno strumento / linguaggio per la comunicazione tra gli sviluppatori.

Una diversa implementazione del modello porta a confusione, a false assunzioni e distorce la comunicazione.

Quindi, riguardo alla domanda

Should there be one class called PersonModel, which contains both state and behaviour if a rich Domain Model is by the business layer/domain layer?

Direi no, non dovrebbe .

In entrambi i casi (MVC e MVP), dovrebbe essere controller / presentatore che chiama la chiamata al servizio. Nell'abscence del livello di servizio, questi due componenti eseguono la chiamata ai componenti di livello superiore del modello di dominio. Ad esempio, per i repository .

Inoltre, altri due motivi potrebbero essere che, nell'esempio sopra, si rompe la coesione e si viola l'SRP.

    
risposta data 07.06.2017 - 18:21
fonte

Leggi altre domande sui tag