• Choose a category
• All
• Classic-Fiction

By Root 5480 0

presenter is clearly part of the presentation layer. In a layered solution, the presentation layer is where you bridge the middle tier. The nearest endpoint in the middle tier land is the service layer, as discussed in Chapter 14. The service layer is a collection of classes (sometimes just WCF services) that orchestrate all the actions required by the application logic to serve a given request. The service layer should accept and retrieve data in a format that suits the presentation; if necessary, the service layer will translate from middle tier entities to presentation-only data transfer objects. If you’re lucky, you can even use the same entities on both the presentation and business layers.

Note

In this regard, your luck mostly depends on the complexity of the use-case and the complexity of the problem’s domain. In many cases, you can’t just find a match between middle tier models and view models. When this happens, using two distinct object models is the only way to go.

The presenter needs a reference to one or multiple objects in the service layer assembly. This means that, in the first place, the presentation layer needs to reference the service layer assembly. More importantly, you must inject in the presenter a reference to the specific service it will be using.

In the previous listing, I used the poor man’s dependency injection approach. It consists of an overloaded constructor that defaults to a concrete class in production. However, by using a different constructor, you can support a fake layer for the purpose of unit testing. You can use any Inversion of Control (IoC) tool of choice here if you like that best.

Hence, the presenter places a single call to the service layer to grab all it needs in the context of that use-case. The service layer returns data that the presenter will then incorporate in the view. The communication between the presenter and the service layer can be both synchronous and asynchronous, depending on your needs.

Note

The service layer typically (but not necessarily) lives in its own assembly on the same server that hosts the Web application. With this configuration, there’s no need for you to implement the service layer as real WCF services. It becomes a necessity, instead, as soon as you need to use queued or transactional calls or just to deploy the middle tier on a different machine for scalability reasons.

Presenter in Action

Wrapping up, the user is displayed a page with server controls for input as usual. The user interacts with the page and causes a postback. On the server, the request is processed as usual and results in a page call.

During the page loading, the presenter is instantiated and receives a reference to the current page object. The postback event originates a call to a method in the presenter. The method typically uses the view object to retrieve input data and places a call to the service layer.

An operation develops on the server and a response is served back to the service layer and, from there, is served to the presenter. Finally, the presenter updates the view. (See Figure 15-7.)

Figure 15-7. MVP is used under the hood, but you can’t see it from the UI.

Sharing the Presenter with a Windows Application

Admittedly, the feature I’m going to discuss is pretty cool and makes for a compelling demo. There’s no magic behind it, and I consider it to be a lucky scenario—real, but special. Under certain conditions, the presenter can be shared with the same application written for other platforms, such as Windows Forms and WPF. (See Figure 15-8.)

All that you need is a Windows form that implements the same view interface. At that point, the presenter has all it needs—a view object. What about the service layer? If you can’t reuse the same service layer you had for the Web application, the dependency injection design you adopted for the presenter class makes it easy to change to a more specific one:

public partial class DefaultForm : Form, IDefaultView

{

private DefaultPresenter _presenter;

public DefaultView()

{

InitializeComponent();