Загрузка подпредставлений с MVP

Взгляните на этот другой вопрос SO . Хотя это относится к WPF, а не к WinForms, проблема, похоже, та же.

По сути, я считаю, что необходимость показывать вспомогательное окно как Service (вы могли бы назвать его WindowsService или DialogService или что-то в этом роде). Это помогает вам взглянуть на вещи в перспективе, потому что, как только вы это поймете, ответом становится внедрение зависимостей.

В своем ответе вы моделируете это с помощью событий, но я предпочитаю более явную модель, в которой вы вызываете метод ShowDialog DialogService. . Однако механика каждого подхода не сильно отличается.

Пара комментариев по этому поводу

Первый Это

    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.
    }

Что произойдет, если вы решите заменить SecondForm на ThirdForm? Вам нужно найти каждый вызов newform = new SecondForm и внести изменения.

Вместо этого вы должны заключить создание SecondForm в объект Command

   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.
        }

    }

Затем здесь и в любом другом месте появляется вторая форма, использующая этот синтаксис

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

] Если вы хотите заменить SecondForm совершенно новой формой, тогда у вас есть только одно место, куда вам нужно пойти. Если вы хотите передать значения статуса или настройки, используйте конструктор команды. Вы даже можете передать другой Presenter или View и заставить команду извлекать информацию из его интерфейса.

Еще я рекомендую вам зарегистрировать формы, реализующие ваши представления, вместо использования новой команды. Это делается во время инициализации, и реестр зависает от вашего основного класса приложения.

Например.

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

где-то еще в программном обеспечении

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

        //Stuff ....

}

Затем команда настраивается следующим образом.

   public class CreateSecondForm : ICommand
    {
        myApp theApp;
        public CreateSecondForm(myApp thisApp) {
           theApp = thisApp;
        }

        public void Execute() {
            SecondForm newform = theApp.Find(ViewFormEnum.SecondForm);
            if (newForm != null) 
               newform.Load(); // Load the form and raise the events on its presenter.
        }

    }

Простите мой C #, это не мой основной язык. Преимущество этого подхода заключается в том, что сборку, содержащую формы, можно заменить другой сборкой с другим набором форм. Это особенно полезно для автоматизации тестирования, когда вместо формы можно создавать фиктивные классы. Вы также можете настроить его для обработки нулевых представлений, что полезно для выпуска подмножества вашего полного приложения.

Хотя я настоятельно рекомендую вам использовать эту команду для завершения создания ваших представлений. Второе предложение регистрации View может быть излишним в зависимости от приложения. В моем приложении CAD / CAM у меня есть десятки диалогов и несколько различных основных форм, используемых для различных аспектов настройки и управления столом для 2D-резки металла. Однако в некоторых других приложениях моей компании я использую простой подход, так как в основном это простые утилиты.