Waar moet Bekijk & Presenter worden geboren

stemmen
5

Ik begrijp volkomen de MVP patroon nu, maar ik heb nog steeds moeite om te zien waar standpunten en presentatoren worden geconcretiseerd. Ik heb een aantal voorbeelden waarbij de presentator up wordt vernieuwde in het oog gezien, maar dit is correct. Na het lezen van een blogpost van Jeremy Miller over de communicatie tussen View en Presenter had hij een functie op de Presenter om de presentator te hechten aan het uitzicht.

Mijn vraag is dan is deze: Waar moet bekeken en presentatoren worden gecreëerd? Ook de plaats waar in winforms en webformulieren.

De vraag is gesteld op 09/12/2008 om 23:04
bron van user
In andere talen...                            


3 antwoorden

stemmen
3

In webformulieren, krijgt de pagina geconcretiseerd door het verzoek. Omdat de pagina is het uitzicht en je kunt geen controle over de volgorde van uitvoering, is van mening dat moet zich inschrijven bij de presentator

antwoordde op 09/12/2008 om 23:15
bron van user

stemmen
2

In WinForms, een instantie van het uitzicht als nodig is (bijvoorbeeld: in de mainmethode, of in een methode op een andere presentator, maar waar is logisch eigenlijk). Het uitzicht maakt vervolgens en meldt zich een nieuwe instantie van een presentator.

Dit maakt het hebben van verschillende aanzichten maken gebruik van dezelfde presentator logica eenvoudig, en schilden de gebruikers van mijn uitzicht vanuit mijn bijzondere architectonische beslissing om MVP te gebruiken.

antwoordde op 09/12/2008 om 23:28
bron van user

stemmen
1

In de eerste plaats goede vraag. Ten tweede kan het niet uit, veel. Mijn persoonlijke voorkeur gaat uit naar bijna altijd bedraden Presenter en View in de View.

Vergelijk dit scenario:

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();
    }
}

om dit:

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);
    }
}

Zoals je kunt zien dat de laatste heeft veel minder code duplicatie. Dat is natuurlijk dom verdubbeling of je zou kunnen zeggen dat je kunt hier veel voorkomende functionaliteit naar een gedeelde functie moet komen, maar je krijgt het punt, dat is gewoon een voorbeeld .. Dat is wanneer u zal hebben hetzelfde uitzicht te worden geconcretiseerd in meerdere delen van uw aanvraag.

Bovendien is het voordeel van het bekijken het kennen van de Presenter is dat je hoeft alleen Presenter verwijzen in uw View project, zodat u kunt dezelfde Presenter hergebruiken in verschillende UI toepassingen. Anders zal je nodig hebt om elke View project in de Presenter verwijzen ..

Maar wat belangrijker is, is te zien hoe de verschillende modellen passen bij uw zaak. Om eerlijk te zijn, zijn er meer mogelijkheden nog. Zie deze dubbele vraag.

antwoordde op 18/01/2013 om 00:15
bron van user

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