Tag: MVP

Finishing, MVP + E.F. + I.O.C. + D.I.

6 Nov 2014 Miguel Ángel Utiel Peñaranda Leave a comment

End step in our Project. We will try to give more independency to each Project with Inversion of Control (IOC) and Dependency Injection (DI). What are these two concepts and his benefits?

I.O.C. Commonly, in the normal workflow, our code calls an specific method in a library. In IOC, we call a generic interface that returns an expected response, but the responsibility to know what method needs to call is from an external source. Sometimes this implementation is called “Hollywood Principle” due to the common phrase “Don’t call us, we call you”.

D.I. This pattern is used with IOC models to supply the implementations of the methods dynamically instead call the method directly like in the normal flow. D.I. is who manage the relation between the interfaces used in IOC with his implementation.

Ok, after the theory, is time to implement that.

How to start? The first step is start with IOC, creating the interfaces for our methods. We are going to separate the Contracts in 3, “Views”, “Services” and “Data”.

The first one is for our views, the second for the services (that are called from presenters and calls data) and the data (that has the communication with our database). The objective is not call the methods directly, all calls should be through interface.

We have created and interface for data with our method and we have inherited from it in our Data Access repositories.

1

Now we need to create a service that is the responsible to call this methods (always through the interface. We cannot call the methods directly). We need to create a project to put the services (or we can call the data layer directly from the presenter, but is recommended to have an intermediate layer).

2

We need to have a variable with our Repository (always through the interface) and call the methods of our interface (not the class directly as in a common x-layer design). We need to initialize it in our constructor as you can see in the image. We can have more than one repository in our services layer.

The end step is to replace our call in the presenter for our service layer. Again we will need a variable of our service layer that should be initialized in the constructor.

3

Now, we have implemented IOC, we have not called any method because we are delegated this to the interfaces. Doing this, we cannot know, who or how the method will be resolved.

Probably you are thinking, “How I know that I’m calling the right method? Which method are calling?” Solve this is the responsibility of D.I. Our D.I. manage the “routing” of the methods to call. We have chosen Unity, that is the D.I. proposed by Microsoft.

To install Unity we can use Nuget.

4

Ok, the first step is configure it. I prefer to configure it through xml because is more flexible than by code (we can change it at runtime and we don’t need to compile it and deliver a new version). We have created a file to put the configuration (UnityConfigFile.config).

By one hand we need to put our interfaces registering an alias.

5

By the other hand we need to specify which class (that implements this interfaces) will be used.

6

Finally we need to initialize the Unity Provider in our global.asax. We have created a class called InjectionProvider to register Unity. You can copy/paste it in your Project to use it.

7

And we need to create the presenter in the view through InjectionProvider.

8

Maybe you can have an error (The type name or alias MVP.Model.BookRepositoryEf, MVP.Model could not be resolved. Please check your configuration file and verify this type name.). This error is due to the libraries. You don’t have any reference to your “Model” and “Service” Project, so Unity cannot find it, you need to add your dll to the bin folder. You can do it manually or with post-build events.

Now our methods are managed by the D.I., so if we want to change how the application works, we only need to change the xml file. You can do the test changing the data Access layer (we have both, one with E.F. and another one with a static list) and you will see that the functionality of your application changes only changing a xml file.

9

You need to think that now you have small blocks (classes that implement interfaces) and you can connect this classes dynamically. You can think in the teleoperators of last century with his cables connecting the class dynamically depending who calls.

10

For WinForms and WPF you need to do the same. Add Unity, include the InjectionProvieder, call the initializer and create the presenter in the view trough Unity.

You can download the code here.

Multi Language Applications – Localizations

25 Oct 2014 Miguel Ángel Utiel Peñaranda Leave a comment

This is the last post about improvements to our applications, the multi language.

Sometimes, our application needs to be in different languages. For do that, .not bring us the possibility to have different resource files and choose between them. I always recommend use it, even if the application is in one language only because maybe in the future we can translate it and, if we don’t have use it resources, the work can be very huge.

We are going to create a new Project with the resources to be able to shared between the three UI projects. We need to add one for each language like the image.

1

As you can see, one is the main (we will use the names of properties in this file) and additional resources for the other languages (french, spanish and portuguese).

2

In the applications, we need to put the resources property instead put the word directly.

3

To test it, we can add a globalization parameter to change easily the language or we can manage it through the application, depending the selection of the language, the user, etc.

4

For Desktop applications we can use the same methodology. We only need to specify the resource to use in the “Designer.cs” file and again, choose the language to use.

5

And the same for WPF applications.

6

You can download the code of this post and the previous (E.F. + routes) here.

Adding Entity Framework

12 Oct 2014 Miguel Ángel Utiel Peñaranda Leave a comment

In this post, we will talking about some improvements to do in our application. We will introduce E.F. That don’t have nothing to see with MVP pattern but we will use the Project of the previous post about MVP. In any case, you can apply this improvements in other projects.

The first step is create the database. In our case a book store database.

1

After create the database, we need to create a ADO.NET Entity Data Model

2

We follow the instructions and we can select the objects to import (Table, Views, procedures, …). In our case we are going to select the tables (we can add, remove, update later).

3

In our Diagram, and if we don’t have the foreign keys in the database or we want to add additional associations in the model, we can do it through the Diagram. To do it, we need to select one entity > Add new > Association.

4

After that, we select the relation (the line) and we need to specify the fields of the relation.

5

After finish the associations, our model should be something like that:

6

Next step is separate our entities. By default, the entities are been created in the same folder and Project than our model. This not respect the X-Layer design, so we should have the entities in another Project. Do that is very easy from versión 5.X of Entity framework. We only need to move the “.tt” file to the Entities Project.

7

When we have the file in the other Project, we need to change the file to put where are located the model in the the inputFile variable.

8

If all Works fine, we can see that our classes are been created in this new Project. Now we have all separated, so we can continue. We need to take into account that if we modify something from our Model, we need to come to this file and make some modification (or only save again) to reload the changes in this file.

We have created a new class to connect to E.F. and retrieve data

9

Now we only need to change our presenter to call this class instead the previous one and change the data source. (We have removed the old Book entity and replace by the new one of E.F.). Probably we are going to get an error trying to connect, due to the local database (“Error finding books. No connection string named ‘BookStoreEntities’ could be found in the application config file.”). We need to add the connection to the Project config file (we can see it in the Model Project) and add the EntityFramework library (EntityFramework.SqlServer.dll).

We can see that now, the result are retrieved from the database.

10

MVP Pattern. Part 1

4 Oct 2014 Miguel Ángel Utiel Peñaranda Leave a comment

We are going ot start to talk, in several posts, about MVP, how to implement it and some improvements in the pattern (IOC, DI).

What is MVP? MVP is a pattern, similar to MVC or MVVM, that allows us to separate our interface and our logic. With this pattern we can have our logic and different UI implementations (Web, Foms, WPF, Silverlight, …). Our UI is irrelevant, so we can migrate our applications through different tecnologies only designing a new UI.

MVP is a user interface architectural pattern engineered to facilitate automated unit testing and improve the separation of concerns in presentation logic:
• The model is an interface defining the data to be displayed or otherwise acted upon in the user interface.
• The view is a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data.
• The presenter acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view.
Here some differences between MVP and MVC.

Here some differences between MVP and MVC.
1

So ok, now is time to know how to implement this pattern. Let’s do it.

The first step is the same than always, create the different proyects involved in our application. We will have a Project for our Presenters, another one for our Interfaces (Contracts), one for model (database), entities and different projects for our different UI.

2

The best way to start is to create the interfaces (in contract Project) and entities. In this example we are going to create a book store and the first step will be list our books.
We will create a interface called IBookListView (from now to the end we will call the interfaces as IxxxxxView). This interface will be contain all the properties needed for our UI screen. That means, we will need a property for each control in the screen and for each event (all interactions with the screen). For the moment it doesn’t matter what kind of control is.

3

We have a property to find a books, a list with all books and a event for find. This are the elements that our screen should have (again, it doesn’t matter the kind of control or the UI Project. The objective is to reduce the coupling between projects). For events, we can use custom events or base events.

Ok, now we can start with our Model layer. We need to retrieve the books based on the title to find. For now, we will implement our database as a static List. In future posts, we will introduce E.F. for the database.

4

Now we have our database logic. The end step is to manage the logic of the application. For this purpose are the presenters. Our presenter should have our view to manage the properties and events.

5

In this case is easy. We will find the books and if we get some error, we have created a property (MessageLabel) to display the error (we need to create it in the contract). As we can see, we don’t have any reference to controls or something similar. This Project should be totally independent from System.Windows.Forms or System.Windows.Web libraries. These projects are independent from the chosen UI.

Our last step, our UI. We design the UI and after that, we need to inherit from our Contract.

6
7
8

fter finish our UI, and as we comment above, we need to implement our Contract or interface. We need, at this point, associate our properties to our controls in each UI. If we use the same names in the three applications will be more easy.

9
10

11

As you can see, almost the 90% of the code is exactly the same between three UI applications. In fact if you have the same names in the controls you can copy/paste the entire code. You can see in addition that the same code are shared by the three applicantions only detailing the presenter to use (BookListPresenter).
With MVP we can separate our UI from our logic and we can have part of the team focus on the UI and another part in the database or logic. Is easy to divide the tasks between the team.

12

 

You can download the code here.