Model-Widok-prezenter w WinForms

To jest moje skromne podejście do MVP i Twoich konkretnych problemów.

Po pierwsze, wszystko, z czym użytkownik może wchodzić w interakcję lub po prostu być pokazane, jest widokiem. Prawa, zachowanie i cechy takiego widoku są opisane przez interfejs . Ten interfejs może być zaimplementowany przy użyciu interfejsu WinForms, interfejsu konsoli, interfejsu webowego lub nawet w ogóle (zwykle podczas testowania prezentera) - konkretna implementacja nie ma znaczenia, dopóki przestrzega praw swojego widoku interfejs.

Drugi , widok jest zawsze kontrolowany przez prezenter. Prawa, zachowanie i cechy takiego prezentera są również opisane przez interfejs . Interfejs ten nie jest zainteresowany konkretną implementacją widoku, o ile przestrzega praw swojego interfejsu widoku.

Po Trzecie , ponieważ prezenter kontroluje swój widok, aby zminimalizować zależności, naprawdę nie ma korzyści z posiadania widoku wiedząc cokolwiek o jego prezenter. Istnieje uzgodniona umowa między prezenterem a widokiem i jest to określone przez interfejs widoku.

Implikacje trzeciej to:

• prezenter nie ma żadnych metod, które Widok może wywołać, ale Widok ma zdarzenia, które prezenter może subskrybować.
• prezenter zna swój pogląd. Wolę to osiągnąć wtryskiem konstruktora na betonowy prezenter.
• widok nie ma pojęcia, co to jest prezenter kontrolowanie go; po prostu nigdy nie zostanie dostarczony żaden prezenter.

Dla Twojego problemu powyższy może wyglądać tak w nieco uproszczonym kodzie:

interface IConfigurationView
{
    event EventHandler SelectConfigurationFile;

    void SetConfigurationFile(string fullPath);
    void Show();
}

class ConfigurationView : IConfigurationView
{
    Form form;
    Button selectConfigurationFileButton;
    Label fullPathLabel;

    public event EventHandler SelectConfigurationFile;

    public ConfigurationView()
    {
        // UI initialization.

        this.selectConfigurationFileButton.Click += delegate
        {
            var Handler = this.SelectConfigurationFile;

            if (Handler != null)
            {
                Handler(this, EventArgs.Empty);
            }
        };
    }

    public void SetConfigurationFile(string fullPath)
    {
        this.fullPathLabel.Text = fullPath;
    }

    public void Show()
    {
        this.form.ShowDialog();        
    }
}

interface IConfigurationPresenter
{
    void ShowView();
}

class ConfigurationPresenter : IConfigurationPresenter
{
    Configuration configuration = new Configuration();
    IConfigurationView view;

    public ConfigurationPresenter(IConfigurationView view)
    {
        this.view = view;            
        this.view.SelectConfigurationFile += delegate
        {
            // The ISelectFilePresenter and ISelectFileView behaviors
            // are implicit here, but in a WinForms case, a call to
            // OpenFileDialog wouldn't be too far fetched...
            var selectFilePresenter = Gimme.The<ISelectFilePresenter>();
            selectFilePresenter.ShowView();
            this.configuration.FullPath = selectFilePresenter.FullPath;
            this.view.SetConfigurationFile(this.configuration.FullPath);
        };
    }

    public void ShowView()
    {
        this.view.SetConfigurationFile(this.configuration.FullPath);
        this.view.Show();
    }
}

Oprócz powyższego, zwykle mam podstawowy interfejs IView, w którym przechowuję Show() i każdy widok właściciela lub tytuł widoku, z którego moje widoki zwykle korzystają.

Na twoje pytania:

1. gdy winform ładuje się, musi uzyskać widok drzewa. Czy mam rację myśląc, że view powinien zatem wywołać metodę taką jak: presenter.gettree(), to z kolei będzie delegować do modelu, który uzyska dane do widoku drzewa, utworzy go i skonfiguruje, zwróci go do prezentera, który z kolei przejdzie do widoku, który następnie po prostu przypisze go do, powiedzmy, panelu?

Zadzwoniłbym IConfigurationView.SetTreeData(...) z IConfigurationPresenter.ShowView(), tuż przed wywołaniem do IConfigurationView.Show()

2. czy to będzie to samo dla każdej kontroli danych na Winform, jak I masz datagridview?

Tak, zadzwoniłbym po to. Do widoku należy sformatowanie danych mu podanych. Prezenter po prostu przestrzega umowy widoku, że chce danych tabelarycznych.

3. Moja aplikacja, ma wiele klas modeli z tym samym montażem. Obsługuje również architekturę wtyczek z wtyczkami, które należy załadować przy starcie. Czy Widok wywoła po prostu metodę prezentera, która z kolei wywoła metodę, która ładuje wtyczki i wyświetlać informacje w widoku? Która warstwa będzie następnie kontrolować odniesienia do wtyczek. Czy Widok zawiera odniesienia do nich lub prezentera?

Jeśli wtyczki są powiązane z widokami, to widoki powinny o nich wiedzieć, ale nie prezenter. Jeśli chodzi o Dane i model, widok nie powinien mieć z nimi nic wspólnego.

4. Czy mam rację myśląc, że pogląd powinien zajmować się każdą sprawą o prezentacja, od koloru węzła treeview, do rozmiaru datagrid itp.?

Tak. Pomyśl o tym jak o prezenterze dostarczającym XML, który opisuje dane oraz o widoku, który pobiera dane i stosuje do nich arkusz stylów CSS. Mówiąc konkretnie, prezenter może wywołać IRoadMapView.SetRoadCondition(RoadCondition.Slippery), a następnie Widok renderuje drogę w kolorze czerwonym.

Co z danymi dla klikniętych węzłów?

5. Jeśli po kliknięciu na treenodes, należy przejść przez konkretny węzeł do prezentera, a następnie prezenter opracuje, jakich danych potrzebuje, a następnie zapyta model o te dane, zanim przedstawi je z powrotem do widoku?

Jeśli to możliwe, przekazałbym wszystkie dane potrzebne do przedstawienia drzewa w widoku w jednym ujęciu. Ale jeśli niektóre dane są zbyt duże, aby można je było przekazać Od początku lub jeśli mają charakter dynamiczny i wymagają "najnowszej migawki" z modelu( za pośrednictwem prezentera), to dodałbym coś w rodzaju event LoadNodeDetailsEventHandler LoadNodeDetails do interfejs widoku, aby prezenter mógł się do niego zapisać, pobiera szczegóły węzła w LoadNodeDetailsEventArgs.Node (być może poprzez jego ID) z modelu, aby Widok mógł zaktualizować wyświetlane szczegóły węzła, gdy powróci delegat obsługi zdarzenia. Należy pamiętać, że wzorce asynchroniczne mogą być potrzebne, jeśli pobieranie danych może być zbyt wolne, aby zapewnić dobre wrażenia użytkownika.