I think your very close to having a working MVP-like solution. Let me show you how I'd re-structure your Presenter, and give you a partial idea of how the View can interact with the Presenter.
First, let's modify the default Application start-up code in the Program.cs Class so that it invokes a method, 'ApplicationStart in the Presenter which will be declared as a static Class:
using System;
using System.Windows.Forms;
namespace MVP_View
{
static class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Presenter.DataPresenter.ApplicationStart();
}
}
}
The Presenter:
using System.Collections.Generic;
using System.Windows.Forms;
namespace Presenter
{
public static class DataPresenter
{
static Procedures_Model.DataProcedures dataprocedures = new Procedures_Model.DataProcedures();
public static void ApplicationStart()
{
Application.Run(new MVP_View.DataViewer());
}
public static void SaveData(string first, string last)
{
dataprocedures.SaveData(first + " " + last);
}
public static List<string> GetNames()
{
return dataprocedures.load_names();
}
}
}
</string>
Now, let's look at how one event in the View can interact with the Presenter:
private void but_saveNames_Click(object sender, EventArgs e)
{
Presenter.DataPresenter.SaveData(textBox_firstname.Text, textBox_surname.Text);
}
And, here's a partial "sketch" of the event handler to get the names shown in the RichTextBox in the View:
private void but_showAll_Click(object sender, EventArgs e)
{
richTextBox_allNames.Clear();
if (names.Count == 0)
{
richTextBox_allNames.Text = @"No names are currently saved.";
}
else
{
}
}
For you to think about:
0. in this implementation there is a (relatively small) "coupling" of the View and the Presenter caused by the fact that public static methods are exposed in the Presenter ... that means those methods are potentially exposed to other objects/classes ... what would be an alternative to reduce this coupling: to make the View more "stupid:" yes, in MVP, it's a good thing for the View to be stupid.
1. doesn't a real MVP architecture require use of an Interface ?
2. isn't a real pay-off of having an MVP architecture the ability to create multiple Views, and enable automatic updating of multiple Views as the data changes ... the change perhaps originating from any/all Views ... for which using an Interface comes in handy ? Where would an Interface be defined in an MVP implementation ?
3. what would supporting multiple views, and automatic updates of multiple views, involve ?
4. how would you create a Form to be used as a template for creating multiple views, and how would you then alter instances of this template Form to remove UI elements you didn't want ?