In MVP, dovremmo chiamare repository dal modello o dal presentatore?

5

Nota: l'esempio in questa domanda è per dimostrazione. Concentrati sulla questione e non sui problemi nell'esempio (come l'accoppiamento stretto, la mancanza di Iniezione delle dipendenze ecc.).

Ho un modulo per creare un contatto con un pulsante per salvarlo. Qui ci sono View e Presenter (scritto in C #).

Visualizza:

class View : Form
{
    Presenter presenter;
    public Contact Contact
    {
        get { /* getting logic */ }
    }

    View()
    {
        presenter = new resenter(this);

        InitializeComponent();
        SetEvents();
    }

    void SetEvents()
    {
        saveButton.Click += presenter.SaveButton_Click;
    }
}

Presenter:

class Presenter
{
    View view;
    Model model;

    Presenter(View view)
    {
        this.view = view;
        this.model = new Model();
    }

    public void SaveButton_Click()
    {

    }
}

La mia domanda è ciò che dovrebbe essere scritto in SaveButton_Click . Dovrei chiamare direttamente ContactRepository :

public void SaveButton_Click()
{
    ContactRepository.Save(view.Contact);
}

O piuttosto crea un metodo Save nel Model che chiama ContactRepository :

public void SaveButton_Click()
{
    model.SaveContact(view.Contact);
}
.
.
.
class Model
{
    public void SaveContact(Contact contact)
    {
        ContactRepository.Save(view.Contact);
    }
}

Qual è il modo corretto? I primi principi di break MVP , o il secondo è solo la creazione di metodi non necessari?

    
posta Sipo 27.03.2017 - 12:37
fonte

2 risposte

5

In un modello MVP , il relatore funge da middleman tra la vista e il modello.

Di conseguenza, dal presentatore dovrai chiamare il modello e non cortocircuitarlo chiamando direttamente repository .

Il modello deve prendersi cura della persistenza, incluso il blocco se necessario, mantenendo unità di lavoro , il caching ( ad es. con una mappa delle identità ) o qualsiasi altra cosa sia necessaria.

Se dovessi chiamare direttamente il repository, potresti non essere a conoscenza di tutti questi aspetti e finire con qualcosa che non funziona come dovrebbe, o creare dipendenze indesiderate (tra il presentatore e gli interni del modello), o entrambi .

    
risposta data 27.03.2017 - 14:33
fonte
5

Nella mia esperienza dipende da chi chiedi (ma non dovrebbe).

Ho visto la tua domanda su MVC, MVP e MVVM. C'è confusione su tutti e tre. Ma perché è così?

Questa è principalmente la conseguenza di un fraintendimento su cosa sia il Modello .

Per alcuni il modello è semplicemente un oggetto stupido che contiene dati. Per questa interpretazione del modello è chiaro che non può essere responsabile del richiamo di chiamate al resto dell'applicazione (ad esempio, utilizzando un repository)

Tuttavia, direi che questa interpretazione non è valida.

Ad esempio, nel mondo MVVM il ViewModel è responsabile per l'incollaggio del modello alla vista. Visualizza è responsabile dell'interazione con l'utente. Per processo di eliminazione, tutto il resto ricade sotto la responsabilità del Modello .

Le persone spesso cercano di mettere la logica di business nei loro ViewModels, ma questo sconfigge lo scopo del pattern MVVM, che è quello di separare i problemi dell'interfaccia utente dalle preoccupazioni delle applicazioni. Invece, l'unica responsabilità di ViewModel è di incollare il Modello (i suoi dati, funzionalità e comportamenti) alla Vista.

Non sono un esperto di MVC o MVP, ma da quello che ho capito i principi sono più o meno gli stessi. I Controllori o Presentatori sono facilitatori e non professionisti.

Questo significa che il tuo modello deve essere più di un semplice dato vapid.

    
risposta data 27.03.2017 - 14:44
fonte

Leggi altre domande sui tag