Programming Microsoft ASP.NET 4 - Dino Esposito [322]
public partial class Default : Page, IDefaultView
{
private DefaultPresenter _presenter = null;
protected void Page_Load(Object sender, EventArgs e)
{
_presenter = new DefaultPresenter(this);
}
protected void btnRefresh_Click(Object sender, EventArgs e)
{
_presenter.Refresh();
}
protected void btnRedirect_Click(Object sender, EventArgs e)
{
_presenter.Redirect();
}
// Implementation of the IDefaultView interface
...
}
From an architectural standpoint, something in the preceding code clashes with common sense: the code-behind class is merely a pass-through layer, so either the code-behind class or the presenter might be perceived as unnecessary layers. The fact is, you can’t easily remove code-behind in ASP.NET Web Forms—not without paying some costs in terms of the decreased productivity of teams. Code-behind classes have been around and have worked for a decade; you can’t just modify the framework to get rid of them. On the other hand, the presenter is just an extra layer you add deliberately with the precise intention of increasing maintainability and testability.
Although it’s not objectively perfect, the code shown earlier is probably the best possible compromise to bring the benefits of MVP to ASP.NET Web Forms.
How Does the Presenter Retrieve Data?
Let’s stop for a while and think about the type of code one would write in the Refresh method of the presenter. Given the use-case (and given the view mockup in Figure 15-6), the method is expected to connect to the application’s service layer and, from there, orchestrate a call to some service that actually provides quote information. The Refresh method needs to know the list of stocks for which you intend to run the query. Where does it get that information?
The list of symbols is typed by the user in a text box; the presenter needs to access the text box but, ideally, you want this to happen without exposing the view inner details to the presenter. (Doing so would bind the presenter to a particular view.) Here’s the code of the -presenter, including its Refresh method:
public class DefaultPresenter
{
private readonly IDefaultView _view;
private readonly IQuoteServices _quoteServices;
public DefaultPresenter(IDefaultView view) : this(view, new QuoteServices())
{
}
public DefaultPresenter(IDefaultView view, IQuoteServices quoteService)
{
_view = view;
_quoteServices = quoteService;
}
public void Refresh()
{
// Get input from the view
var symbols = _view.Symbols;
// Execute the action
var stocks = _quoteServices.GetQuotes(symbols);
// Update the view
_view.Quotes = stocks;
_view.Message = String.Format("Data downloaded at: {0}", DateTime.Now);
}
}
At a minimum, the presenter is injected with the view object (for example, a reference to the ASP.NET page) through the constructor. The presenter, however, is instructed to work only against the members of the view interface. This means that the same presenter could be reused on different client platforms. As long as you have a Web and Windows application that operates according to the same actions, the chances for you to reuse the same presenter are definitely high. (This fact might not be true if you take advantage of some platform-specific features and operate the view through a different set of actions.)
The presenter retrieves any input data it needs from the injected view. For example, it grabs any content in the txtSymbols text box via the Symbols property on the view interface. Likewise, it displays any response, such as the last update time, via the Message property. How the Message and Symbols properties actually operate on the view is transparent to the presenter. This transparency is the guarantee that the presenter is absolutely independent from the view.
Connecting the Presenter to the Service Layer
The