Zobacz gdzie powinien się urodzić i Presenter

głosy
5

I całkowicie zrozumieć wzorzec MVP teraz, ale nadal walczyć, aby zobaczyć, gdzie widoki i prezenterzy są instancja. Widziałem kilka przykładów, gdzie prezenter newed się w widoku, ale jest to prawidłowe. Po przeczytaniu blogu Jeremy Miller o komunikacji między View i prezenter miał funkcję w Presenter, aby dołączyć prezenterowi do widoku.

Moje pytanie brzmi zatem: Gdzie należy poglądy i prezenterzy być tworzone? gdzie również w WinForms i WebForms.

Utwórz 09/12/2008 o 23:04
źródło użytkownik
W innych językach...                            


3 odpowiedzi

głosy
3

W webforms, strona zostanie instancja o wniosku. Ponieważ strona jest widok i nie można kontrolować kolejność wykonywania, jest pogląd, że musi zarejestrować się z prezenterem

Odpowiedział 09/12/2008 o 23:15
źródło użytkownik

głosy
2

W WinForm, I instancji pogląd, zgodnie z wymaganiami (np: w mainmetodzie lub w inny sposób na prezentera, ale wszędzie tam, gdzie naprawdę ma sens). Widok następnie tworzy i rejestruje się z nową instancję prezenter.

To sprawia, że ​​mając kilka widoków używać tej samej logiki prezentera łatwe i tarcze użytkownicy moim zdaniem z mojego szczególności decyzji architektonicznej do wykorzystania MVP.

Odpowiedział 09/12/2008 o 23:28
źródło użytkownik

głosy
1

Po pierwsze dobre pytanie. Po drugie, to może nie ma znaczenia, dużo. Moje osobiste preferencje jest prawie zawsze drut Presenter i widok w widoku.

Porównanie to scenariusz:

public class SomePresenter
{
    public ShowContactView(IContactView view)
    {
        IContact model = new Contact();
        new ContactPresenter(model, view);
        view.Show();
    }
} 

public class AnotherPresenter
{
    public ShowContactView(IContactView view)
    {
        IContact model = new Contact();
        new ContactPresenter(model, view);
        view.Show();
    }
} 

public class YetAnotherPresenter
{
    public ShowContactView(IContactView view)
    {
        IContact model = new Contact();
        new ContactPresenter(model, view);
        view.Show();
    }
} 

public partial class ContactView : Form, IContactView
{    
    public ContactView()
    {
        InitializeComponent();
    }
}

do tego:

public class SomePresenter
{
    public ShowContactView(IContactView view)
    {
        view.Show();
    }
} 

public class AnotherPresenter
{
    public ShowContactView(IContactView view)
    {
        view.Show();
    }
} 

public class YetAnotherPresenter
{
    public ShowContactView(IContactView view)
    {
        view.Show();
    }
} 

public partial class ContactView : Form, IContactView
{    
    public ContactView()
    {
        InitializeComponent();

        new ContactPresenter(new Contact(), this);
    }
}

Jak widać, że ten ostatni ma znacznie mniejszą powielania kodu. Oczywiście, że to głupie powielanie lub można powiedzieć można przenieść wspólną funkcjonalność wspólną funkcję, ale o co chodzi, to tylko przykład .. To wtedy trzeba będzie ten sam widok, aby być instancja w wielu częściach aplikacji.

Ponadto zaletą View znając Presenter jest to, że wystarczy tylko odwołać Presenter w widoku projektu, więc można ponownie użyć tego samego Presenter w różnych aplikacjach UI. W przeciwnym razie trzeba będzie odwołać każdego widoku projektu w Presenter ..

Ale co ważniejsze jest to, aby zobaczyć, jak różne modele dopasowane do sprawy. Szczerze mówiąc, jest jeszcze więcej możliwości. Zobacz ten duplikat pytanie.

Odpowiedział 18/01/2013 o 00:15
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more