Here, I’m following up on my previous
post about making a prototype of the architecture diagram presented.
Please download my revised VS.Net solution
here.
I’ve decided not to repost much of the code because of the amount, but I made
some pretty significant changes. In line with Scott Bellware’s suggestions,
I’ve added more granularity to the View interface so that the view never
actually holds a reference to the business object. The control’s to display
information are exposed as properties (actually, the textbox.Text property is
exposed as a property of the interface), so the presenter can actually change UI
elements through the inderection these properties provide. I defined two events
on the interface as well to denote when the LookUp event first and Persist. My
Presenter doesn’t care about a button click, so when the View experiences a
button click that actually means “LookUp”, it fires the LookUp event, which the
Presenter is listening for.
I will include one bit of code, and that is the IView interface
implementation in my WinForms code-behind class:
73 if(LookUp
!= null) LookUp(sender, e);
74 }
75
76 private void button1_Click(object sender, System.EventArgs e) {
77 if(Persist
!= null) Persist(sender, e);
78 }
79
80 // Below are
interface members
81 public event
System.EventHandler LookUp;
82
83 public event System.EventHandler Persist;
84
85 public
Presenter.ContactPresenter Presenter {
86 get {
return _presenter; }
87 set {
_presenter = value; }
88 }
89
90 public string ContactPhoneNumber {
91 get {
return txtPhoneNumber.Text; }
92 set {
txtPhoneNumber.Text = value; }
93 }
94
95 public string ContactName {
96 get {
return txtName.Text; }
97 set {
txtName.Text = value; }
98 }
99
100 public int ContactAge {
101 get {
return int.Parse(txtAge.Text); }
102 set {
txtAge.Text = value.ToString(); }
103 }
104
105 public string ContactUserName {
106 get {
return txtUserName.Text; }
107 set {
txtUserName.Text = value; }
108 }
109
110 public string UserNameToLookUp {
111 get {
return ddlUserName.SelectedItem.ToString();
}
112 }
113
114 private void Form1_Load(object sender, EventArgs e) {
115 if(_presenter == null) _presenter = new Presenter.ContactPresenter(this);
116 }
The above is a snippet from the form code. Notice how the interface
properties are mapped to the appropriate text box, and the button click handlers
just invoke the events defined by the interface. Now it would be very trivial
to snap a different UI on to the same Presenter.
I used NUnit to hook up unit tests to the entire thing to prove that this
layout was fully testable. Each component at every layer has been tested in
isolation. The interfaces make it easy to make stubs, but interfaces were
mainly used for loose-coupling. I’m tightly coupled where concrete classes are
referenced, but that’s fine. I think that loose-coupling should server a
purpose, so it may not be appropriate everywhere. For instance, my Presenter is
tightly coupled with the Repository object. I can still test my Presenter is
isolation because I have a property in my Presenter to hold a reference to the
Repository. In my test, I inherit from the Repository, override the members,
and set the Presenter’s property to my stub object. This isolates Presenter.
I was a bit surprised at how simple my tests ended up being because each
class served a specific purpose, so it was easy to test for that purpose. As
long as my Presenter could call the Repository, it was working. As long as the
Repository could get a Contact back from the ContactData object, it was
working. Only my unit test for MyContactData actually tested that the data was
correct because the object was being created at this point.
Another point of interest is the amount of private methods in my solution.
My two event handlers in the Presenter are private, and that is it. Everything
else is a publicly exposed piece of a concrete class that serves a distinct
purpose.
Download my code and give it a look. I’m open for criticism. Maybe with a
little collaboration, we can, as a community, make architecture recommendations
and provide a community-supported prototype of a single feature demonstrates the
use of good practices. The more feedback the better.