Chargement des sous-vues avec MVP

Question

J'ai joué avec le modèle MVP en utilisant des winforms depuis quelques jours, il y a seulement une chose que je ne sais pas comment faire. Comment créez-vous un sous-formulaire à partir d'une autre vue. Serait-ce une option valide.

public class MyForm : IMainFormView 
    { 
     private MainFormPresenter pres; 
     public MyForm() { pres = new MainFormPresenter(this); } 

     //Event from interface. 
     public event EventHandler<EventArgs> LoadSecondForm; 

     public void SomeButtonClick() 
     { 
      LoadSecondForm(this, EventArgs.Empty); 
     } 
    } 

    public class MainFormPresenter 
    { 
     private IMainFormView mView; 

     public MainFormPresenter(IMainFormView view) { 
      this.mView = view; 
      this.Initialize(); 
     } 

     private void Initialize() { 
      this.mView.LoadSecondForm += new EventHandler<EventArgs>(mView_LoadSecondForm); 
     } 


     private void mView_LoadSecondForm(object sender, EventArgs e) { 
      SecondForm newform = new SecondForm(); //Second form has its own Presenter. 
      newform.Load(); // Load the form and raise the events on its presenter. 
     } 
    } 

Je suis surtout préoccupé par la façon dont vous charger un sous-formulaire en utilisant ce modèle, et comment vous passeriez dire une carte d'identité de la première page à la sous-formulaire.

Merci.

Answer 1

http://www.rickardnilsson.net/post/The-Humble-dialog-v2.aspx

Le lien ci-dessus est le plus proche que je l'ai vu à répondre à ce sujet. La plupart des tentatives de résoudre cela laisse à désirer.

Answer 2

Jetez un coup d'œil à this other SO question. Bien qu'il se rapporte à WPF et non WinForms, le problème semble être le même. Essentiellement, je considère le besoin de montrer une fenêtre subsidiaire un service (vous pourriez l'appeler le service de Windows ou DialogService ou quelque chose comme cela). Cela vous aide à mettre les choses en perspective, car dès que vous réalisez cela, l'injection de dépendance devient la réponse.

Dans votre réponse, vous modélisez ceci avec des événements, mais je préfère un modèle plus explicite où vous invoquez la méthode ShowDialog d'un DialogService. Cependant, les mécanismes de chaque approche ne sont pas si différents.

Answer 3

Quelques commentaires sur ce

Première Ce

private void mView_LoadSecondForm(object sender, EventArgs e) { 
     SecondForm newform = new SecondForm(); //Second form has its own Presenter. 
     newform.Load(); // Load the form and raise the events on its presenter. 
    } 

Qu'est-ce qui se passe si vous décidez de remplacer ThirdForm SecondForm? Vous devez trouver chaque appel de newform = new SecondForm et faire le changement.

Au lieu de cela vous devez envelopper la création du SecondForm dans un objet de commande

public class CreateSecondForm : ICommand 
    { 

     public void Execute() { 
      SecondForm newform = new SecondForm(); //Second form has its own Presenter. 
      newform.Load(); // Load the form and raise the events on its presenter. 
     } 

    } 

Puis ici et tout autre lieu fait apparaître la deuxième forme utilise cette syntaxe

private void mView_LoadSecondForm(object sender, EventArgs e) { 
    CreateSecondForm createCmd = new CreateSecondForm(); 
    createCmd.Execute(); // Load the form and raise the events on its presenter. 
} 

Si vous voulez subsitute une complètement nouveau formulaire pour SecondForm alors vous avez seulement un endroit où vous devez aller. Si vous voulez transmettre des valeurs d'état ou de configuration, utilisez le constructeur de la commande. Vous pouvez même passer dans un autre Presenter ou View et demander à la commande d'extraire les informations de son interface.

Une autre chose que je recommande est que vous enregistrez les formulaires qui implémente vos vues au lieu d'utiliser la nouvelle commande. Ceci est fait pendant l'initialisation et le registre se bloque de votre classe d'application principale.

Par exemple.

public class MySecondForm : ISecondFormView, IViewForm 
    { 
     //Stuff .... 
     Public ViewFormEnum ViewFormType { 
      return ViewFormEnum.SecondForm; 
     } 
     //Stuff .... 
    } 

ailleurs dans le logiciel

public void InitializeApp() { 
     //Stuff .... 
     MyApp.ViewForm.Add(new MySecondForm); 

     //Stuff .... 

} 

Ensuite, la commande est comme configuration cela.Pardon my C# ce n'est pas ma langue principale. L'avantage de cette approche est que l'assemblage contenant les formulaires peut être remplacé par un ensemble différent avec un ensemble de formulaires différent. Ceci est particulièrement utile pour automatiser les tests où des classes fictives peuvent être créées à la place du formulaire. Vous pouvez également le configurer pour gérer les vues nulles, ce qui est utile pour libérer un sous-ensemble de votre application complète.

Bien que je vous recommande fortement d'utiliser la commande pour envelopper la création de vos vues. La deuxième suggestion de l'enregistrement de View peut être excessive en fonction de l'application. Dans mon application CAO/FAO, j'ai des dizaines de boîtes de dialogue et plusieurs différentes formes principales utilisées pour différents aspects de la mise en place et du contrôle d'une table de découpe métal 2D. Cependant, dans certaines autres applications de mon entreprise, j'utilise une approche simple car ce sont principalement des utilitaires simples.