For anyone of you that didnâ€™t read the first part of this article (that I recommend) this is the address.
In this part we will go to build the UI layers, so the user interface, the presentation layer and the Windows form.
The user interface.
In the MVP pattern the interface in the contract that we want to share from the UI and the presenter. In our case we want to add to simple fields, the username and the password. This is a sample:
Now we just have to reflect the two properties in our windows form in this simple way:
And this is the code coming from the view, because of course, in the MVP pattern our UI has to inherit the view.
Now what we need is a method to send messages back to the user and then we can step into the presenter. So letâ€™s declare a sendMessage method in the interface.
And the corresponding implementation in our Windows form:
The presenter in the MVP pattern is the core of the UI. Of course everything has to be executed inside it, and the UI has only to call the corresponding method. Letâ€™s build the presenter and the constructor:
So at this point we go back to the UI and declare and initialize our presenter â€¦
Now we are fine and this is the normal way to use the MVP pattern. But what about the validation??
Validate the valid able â€¦
Suppose that in your presenter you have a simple method called save that will be called by a button in your UI. What you have to do is to check the entity you are going to save, before save it!
Because when we call the method IsValid() we already populate the list of errors in our entity, what we have to do now is to simple read them and build a message for the user:
This is just an example, not very well done, on how to use the UI validation in the MVP pattern. You can agree or you cannot. I always appreciate comments and idea to share.
In the next post I will show you how to build a more strong validation and a simple way to reflect the validation to every simple control of the Windows form with the error component.