c ++ Model View Presenter: Dove costruire il presenter?

8

Sto utilizzando lo schema Model View Presenter (MVP) come descritto in il documento Humble Dialog Box (pdf) con un progetto MFC. Sono sicuro che il problema è lo stesso con la maggior parte dei toolkit della GUI.

La cosa che mi dà fastidio è la visione concreta (cioè la classe di dialogo) che sta creando non solo il presentatore ma anche i servizi di cui il presentatore ha bisogno. È normale? Perché la vista deve sapere di quali servizi ha bisogno il relatore? Quello che sto pensando è che dovrei dipendere dal relatore nella classe di dialogo.

Il controllo principale dell'applicazione è una classe derivata da CWinApp. Quindi dovrei costruire servizi e relatori in questa classe e poi inserirli nella classe di dialogo?

Sebbene in che modo dovrei iniettare il relatore nella classe di dialogo quando il relatore ha bisogno di un riferimento alla classe di visualizzazione nel suo costruttore?

MyPresenter(IView *view, MyService *service);

Inoltre, se la finestra principale si aprisse da una finestra popup, dove dovrebbero essere costruiti i dettagli per il presentatore ei servizi di Windows?

Poiché questo è C ++, non penso che sarei interessato a nessun tipo di framework DI.

Aggiorna

Un'idea che avevo era di costruire il presentatore con una vista nulla, il costruttore inietta il presentatore nella classe di dialogo, e poi nel costruttore della classe di dialogo chiama un metodo SetView(IView *view) sul presentatore con this dove this sarebbe la classe di dialogo (che deriva da IView). Quindi:

MyApp::Start()
{
  SomeService *service = new SomeService();
  MyPresenter *presenter = new MyPresenter(null, service);
  MyDialog *dialog = new MyDialog(presenter);
  ...
}

MyDialog::MyDialog(MyPresenter *presenter):
 presenter_(presenter)
{
  presenter_->SetView(this);
}

Sembra un po 'cauto ma mantiene la costruzione del servizio fuori dalla classe Dialog. La visualizzazione nulla sembra un po 'pericolosa. Un'alternativa sarebbe quella di costruire effettivamente una classe NullView con corpi di metodo vuoti e quindi passarla nel costruttore di presenter.

    
posta User 26.10.2011 - 02:01
fonte

2 risposte

1

Forse una soluzione migliore è usare una classe factory o un metodo che sappia come costruire un presentatore? La vista passerebbe al metodo factory e memorizzerebbe il valore restituito nel suo membro presenter.

Questo disaccoppia le informazioni su come viene costruito un relatore (dipendenze dai servizi o altro) dalla vista stessa.

    
risposta data 21.11.2011 - 13:30
fonte
0

Penso che la tua idea originale (costruire relatore e servizio all'interno della vista) non danneggi. Dobbiamo chiederci il beneficio dell'iniezione e io non ne vedo alcuno.

Separando la vista reale in una vista astratta e un presentatore, hai già raggiunto la separazione delle preoccupazioni. E puoi trarre beneficio dal risultato, ad esempio, testando il presentatore con una vista imbalsamata o derisa. Quindi, perché dovresti iniettare il presentatore in una vista concreta? Non vedo alcuna necessità.

    
risposta data 08.01.2012 - 04:42
fonte

Leggi altre domande sui tag