Programming Microsoft ASP.NET 4 - Dino Esposito [325]
public class SiteNavigationWorkflow : INavigationWorkflow
{
public void Goto(String view)
{
switch (view)
{
case "home":
HttpContext.Current.Response.Redirect("/default.aspx");
break;
case "test":
HttpContext.Current.Response.Redirect(
HttpUtility.UrlEncode(String.Format("/test.aspx?x='{0}'",
Navigator.Argument)));
break;
}
}
public void NextViewFrom(String currentView)
{
switch (currentView)
{
case "home":
// Calculate next view using logic
break;
}
}
}
As an example, let’s have a look at a possible implementation of the same interface for a Windows Forms application:
public class AppNavigationWorkflow : INavigationWorkflow
{
private Form _fooForm;
private readonly Form _defaultView;
public AppNavigationWorkflow(Form main)
{
_defaultView = main;
}
public void Goto(string view)
{
switch (view)
{
case "home":
if (_fooForm != null && !_fooForm.IsDisposed)
{
_fooForm.Close();
_fooForm = null;
}
break;
case "foo":
if (_fooForm == null || _fooForm.IsDisposed)
{
_fooForm = new FooForm();
_fooForm.Owner = _defaultView;
}
_fooForm.ShowDialog();
break;
}
}
public void NextViewFrom(string currentView)
{
switch (currentView)
{
case "home":
// Calculate next view using logic
break;
}
}
}
As you can see, in Windows you might have a radically different approach to navigation, which basically consists of displaying and hiding dialog boxes and windows. Still, from the presenter’s standpoint, all you need to do is invoke the same Goto method:
// From presenter's code
public void Redirect()
{
Navigator.Goto("test", "test value");
}
In ASP.NET, it produces the view shown in Figure 15-10.
Figure 15-10. Navigating to a specific page.
Finally, let’s see how you can attach a platform-specific workflow to the presentation layer. The binding takes place at the application startup—for example, in global.asax:
void Application_Start(Object sender, EventArgs e)
{
var simpleWorkflow = new SiteNavigationWorkflow();
Navigator.Attach(simpleWorkflow);
}
The use of the term “workflow” here is not coincidental. The method Goto in INavigationWorkflow allows you to reach a specific URL; the method NextViewFrom, which can be implemented just by using a workflow based on the current view, determines what comes next.
Testability in Web Forms with MVP
For many years, developers in the .NET space didn’t pay much attention to emerging patterns and practices. The deep application of the RAD paradigm led to a focus on tools and techniques to do it faster, rather than doing it right the first time. Debugging always prevailed over unit testing as the major technique to help check whether your development efforts were on track.
Web Forms has a number of merits, but it certainly doesn’t stand out for the aid it provides with regard to testability. However, using the MVP pattern makes the most relevant part of your Web Forms code—for example, the presenter—far easier to test, and especially unit-test.
Writing Testable Code
If you look at the functionality, there’s nearly no difference at all between testable-code-that-works and untestable-code-that-works. So where’s the benefit of testing? Essentially, it lies in what might happen after you deploy your code to production. The customer might come back and ask you to make changes or implement new features. Or, worse yet, an unexpected bug might show up. In all these cases, you need to put your hands on the code to update it. Your goal is updating what has to be updated without breaking anything else. How do you prove that you didn’t break any existing features?
A well-written set of unit tests can give you the measure of how good your software is now compared to the stage before. If your software still passes all the tests after the updates, well, there’s a great chance that untouched features are still effective.
Aspects