Model view presenter windows

There will be two buttons, one which increments the stock value and the other which decrements the stock value. The stock value is displayed on the stock text box and the color is set according to the value of the stock. All events are first sent to the presenter. So all the events need to connect to some methods on the presenter.

All data needed by the UI, i. Shown below is the interface for the ASPX page. We need the stock value so we have defined a method called setStockValue and we also need the color, so we have defined a method called setColor. The presenter class will aggregate the view class. We have defined an Add method which takes the view object. This view will set when the ASP. NET page starts. When the user presses the increase stock button, it will call the increasestock method of clsPresenter , and when the decrease stock button is called, it will call the decreasestock method of the clsPresenter class.

Once it increments or decrements the value, it passes the value to the UI through the interface. We had also talked about moving the presentation logic in the presenter. So we have defined the ChangeColor method which takes the status from the Stock object and communicates through the view to the ASPX page. In the page load, we have passed the reference of this page object to the presenter. This is necessary so that the presenter can call back and update data which it has received from the model.

As we have inherited from an interface, we also need to implement the method. So we have implemented the setStockValue and the setColor method. The presentation project does, however, have a reference to the service layer project. This allows me to solve the problem by adding an overloaded constructor to the ViewCustomerPresenterClass:. This new constructor satisfies the presenter's requirement for implementations of both the view and the service, while also maintaining the separation of the UI layer from the service layer.

It is now fairly trivial to finish off the code for the codebehind:. Notice the key to the instantiation of the presenter is the fact that I am making use of the newly created overload for the constructor, and the Web Form passes itself in as an object that implements the view interface! With the code for the codebehind implemented, I can now build and run the application. The DropDownList on the Web page is now filled with a list of customer names without the need for any databinding code in the codebehind.

Plus, scores of tests have been run on all the pieces that ultimately work together, ensuring that the presentation layer architecture will behave as expected. I'm going to wrap up my discussion of MVP by showing what is required to display customer information for a customer selected in the DropDownList. Once again, I start by writing a test that describes the behavior I hope to observe see Figure As before, I am taking advantage of the NMock library to create mocks of the task and view interfaces.

This particular test verifies the behavior of the presenter by asking the service layer for a DTO representing a particular customer. Once the presenter retrieves the DTO from the service layer, it will update properties on the view directly, thus eliminating the need for the view to have any knowledge of how to correctly display the information from the object. For brevity I am not going to discuss the implementation of the SelectedItem property on the WebLookupList control; instead I will leave it to you to examine the source code to see the implementation details.

What this test really demonstrates is the interaction that occurs between the presenter and the view once the presenter retrieves a CustomerDTO from the service layer. If I attempt to run the test now, I will be in a big failure state as a lot of the properties don't yet exist on the view interface. Immediately after adding these interface members, my Web Form complains because it is no longer fulfilling the contract of the interface, so I have to go back to the codebehind for my Web Form and implement the remaining members.

This makes the resulting code to implement the interface members very trivial:. With the setter properties implemented, there is just one thing left to do. I need a way to tell the presenter to display the information for the selected customer. Looking back at the test, you can see that the implementation of this behavior will live in the DisplayCustomerDetails method on the presenter. This method will not, however, take any arguments. When invoked, the presenter will turn back around to the view, pull from it any information it needs which it will retrieve by using the ILookupList , and then use that information to retrieve the details about the customer in question.

This event handler ensures that whenever a new customer is selected in the dropdown, the view will ask the presenter to display the details for that customer.

It is important to note that this is typical behavior. When a view asks a presenter to do something, it asks without giving any specific details, and it is up to the presenter to return to the view and get any information it needs using the view interface.

Figure 13 shows the code required to implement the required behavior in the presenter. Hopefully you now see the value of adding the presenter layer. It is the presenter's responsibility to attempt to retrieve an ID for a customer for whom it needs to display details.

This is code that would normally have been performed in the codebehind, but is now inside a class that I can fully test and exercise outside of any presentation-layer technology. In the event that the presenter can retrieve a valid customer ID from the view, it turns to the service layer and asks for a DTO that represents the details for the customer.

A key point to note is the simplicity of the view interface; aside from the ILookupList interface, the view interface consists entirely of string DataTypes.

It is ultimately the responsibility of the presenter to correctly convert and format the information retrieved from the DTO so that it can actually be handed to the view as a string.

Although not demonstrated in this example, the presenter would also be responsible for reading information from the view and converting it to the necessary types that the service layer would expect.

With all the pieces in place I can now run the application. When the page first loads, I get a list of customers and the first customer appears not selected in the DropDownList. If I select a customer, a postback occurs, the interaction between the view and the presenter takes place, and the Web page is updated with the related customer information.

Although this example was fairly simple from a requirements perspective, it should help you abstract the interaction between a UI and the other layers of your applications. Also, you should now see ways that you can use these layers of indirection to make your application more testable with automation.

Send your questions and comments to mmpatt microsoft. Jean-Paul Boodhoo is a senior. NET delivery expert for ThoughtWorks where he is involved in the delivery of enterprise-scale applications that utilize the. So what is the Model View Presenter pattern, and why use it? Well basically, in Model View Presenter, you start off by making each of the UI components in WinForms that would be user controls and forms implement a view interface. The view interface should contain properties that allow the state and content of the controls in the view to be set and retrieved.

It may also include events to report back user interactions such as clicking on a button or moving a slider. The goal is that the implementation of these view interfaces is completely passive. Ideally there should be no conditional logic whatsoever in the code behind of your Forms and UserControls. My vote of 5 srilekhamenon Feb Great article!

The demo is great! So as the article. I think it's quite suitable for beginners. My vote of 3 Ninad K Feb Really good article on MVP. Nice one for a starter ernestohari 7-Oct I was looking for a simple example to start with. After frightening from msdn samples this was good hope. Is it really necessay to use reflection in the presenter? Is it needed just to ensure loose coupling?

On databinding vs. I think decoupling is overrated. You decouple, after all, in order to make your code more maintainable. When you do it just for the sake of decoupling, your code can quickly become a mess of services, interfaces, and abstract factories, just to decouple a call to MessageBox. Back to the article, I think that winforms databinding is much better maintainable than the reflection method presented here.

For example, how do you implement binding a grid to a list of items? Another problem is the requirement that the model properties correspond to these of the view -- isn't it just another form of coupling? On the other hand, you can easily decouple your view from your data if you use a BindingSource object. For example, you may pass an instance of the Order class to your view. In the View code, this instance becomes the data source of the corresponding BindingSource object.

Adding a property to this class doesn't change the interface, just the implementation you might want to add a textbox or a grid column. IUserView hai ping Jun Re: IUserView ke4vtw Sep I haven't investigated this closely, but I would assume that IUserView is implemented either on a WinForm or a WebForm, both of which already have a Show method that would fulfill the contract. Good and clear explanation!

It automates many of the tasks described above, and simplifies MVP pattern usage. Seriously, it's the first time I heard about MVP and I quite like the concept after reading a bit on the subject. Is it intentional? Article Update Markus Klieber Apr Markus Klieber.

Hi Chris, i like your article, but i think you should have to update you description about the MVP. Martin Fowler devided MVP into two new patterns. As i see you described the so called "Passive View" pattern.

I think this is a bit confusing, because the first time i read your article i thought this is the original MVP, but what is "orignial" with all those variants of MVP Why not just use a generic presenter and pass property name Tawani Anyangwe Apr Tawani Anyangwe. I'm just curious, but it seems this single presenter can be extended at reused.

Re: Why not just use a generic presenter and pass property name cgreen69 Apr Hi and thanks for your question. Typically this isn't the case, real world apps have presenters with more logic in therefore I don't think a generic presenter would be suitable. Your second statement is a good suggestion assuming that we want to react straight away to a change. The code I have included with the article allows all values to be synchronised when a particular event occurs, e.