Zdarzenia i MVP w windows forms

Poszukuję porady dotyczącej używania zdarzeń do połączenia elementów we wzorcu MVP (pasywny)
kawałek kodu:

 
public interface IFormView
    {
        string AccountName { get; set; }
        string AccountLogin { get; set; }
        string AccountPassword { get; set; }
        
        event EventHandler BaseAccountListIndexChanged;
    }

public partial class frmAccountEditor : Form, IFormView
    {
        private EditorPresenter _presenter;
        private Model _model;

	public string AccountName //powiązania do textboxów
        public string AccountLogin //powiązania do textboxów
        public string AccountPassword //powiązania do textboxów

	public event EventHandler BaseAccountListIndexChanged;

	//zmiana indexu w listboxie lstEditorAvailableAccounts

	private void lstEditorAvailableAccounts_SelectedIndexChanged(object sender, EventArgs e)
        {
            if (BaseAccountListIndexChanged != null)
            {
                BaseAccountListIndexChanged(this.lstEditorAvailableAccounts.SelectedIndex, EventArgs.Empty);
                //BaseAccountListIndexChanged((sender as ListBox).SelectedIndex, EventArgs.Empty); - może tak?
            }
        }
     }




public class FormAccountEditorPresenter
    {
        IFormView _formView;
        IModel _model;


	FormAccountEditorPresenter(IFormView view, IModel model)
	{
		this._formView = view;
		this._model = model;
		this._formView.BaseAccountListIndexChanged += this.OnBaseAccountListIndexChanged;
	}


public void OnBaseAccountListIndexChanged(object sender, EventArgs e)
        {
            int index = 0;
            if (sender.GetType() == typeof(Int32)) index = (int)sender;
            //zwraca wartości z listy w modelu pod danym indexem do właściwości widoku
            this._formView.AccountName = this._model.GetBaseAccountAt(index).Name; 
            this._formView.AccountLogin = this._model.GetBaseAccountAt(index).Login;            
            this._formView.AccountPassword = this._model.GetBaseAccountAt(index).Password;
            
        }

Czy to jest dobre rozwiązanie? Bo coś czuję, że w widoku gdy korzystam ze zdarzenia zmiany indexu listboxa tworzę jakąś incepcję.
I jeszcze inne pytanie: w takim przypadku gdy muszę przekazać w zdarzeniu nr indexu lepiej korzystać z przekazywanego obiektu czy tworzyć CustomEventArgs : EventArgs i tu przekazywać index?
Pyt. 3: Zakładając, że korzystam z tych CustomEventArgs w interfejsie, to klasa CustomEventArgs powinna się znajdować w osobnym pliku czy może być w tym samym co interfejs? (w przypadku gdy korzystają z niej tylko klasy dziedziczące po tym interfejsie)

1. A czemu w ogóle wysyłać zdarzenie do Prezentera zamiast po prostu wywołać jakąś jego metodę?
2. Jak najbardziej tworzyć nową klasę dla specyficznego zastosowania.
3. Jak wolisz, byle byś trzymał się konwencji - albo w każdym takim przypadku klasa zdarzenia i interfejs widoku razem, albo zawsze oddzielnie.

1. Może to złe podejście ale Widok i Model nic nie wiedzą o sobie nawzajem, o Prezenterze też i mogą się z nim komunikować tylko przez zdarzenia. Natomiast Prezenter zna metody zarówno Widoku jak i Modelu (te dziedziczone po IModel i IView). W teorii miało to ułatwić zmianę Widoku bez potrzeby przebudowywania Prezentera.

Wszelkie materiały jakie znajdowałem do tej pory to proste aplikacje z paroma textBoxami i jedną listą obiektów. Nawet Model był pomijany a lista siedziała w Prezenterze. Szczerze mówiąc to przydałby mi się przykład jakiegoś bardziej rozbudowanego projektu windows forms w MVP żeby sobie zobaczyć jak to dobrze napisać, a nie tylko żeby działało. Coś z kilkoma skomplikowanymi Widokami, Prezenterami i Modelem który faktycznie coś robi.
Jakby ktoś znał coś takiego gdzie można podejrzeć dobre praktyki MVP to z chęcią przygarnąłbym link :)

Na mój gust, to nie ma powodu, żeby widok nie wiedział nic o Prezenterze, ani żeby nie wołał jego metod. Aby móc zmienić Widok bez ruszania Prezentera wystarczy jedynie, aby Prezenter operował na kontrakcie Widoku (interfejsach), a nie konkretnej implementacji. IModel zaś nic pod tym względem nie daje.
Nie mówię, że to źle, to bardzo dobry poziom odseparowania, tylko nie wiem czy warty dodatkowej pracy.