Part 9 - Server Side Setup of Unit of Work for your Mobile App

Now that we have setup our repositories, we need something to manage the repositories and expose them easily to our various services.  To do this, we will implement the Unit of Work pattern.

Start by opening Visual Studio 2017 to our Invoicing solution.  In the Invoicing.Core project, right click on the project and add a new class.  When the pop-up comes up, click the Interface option and name the interface IUnitOfWork.cs.  We’ll use this interface to allow us to implement dependency injection with this class.



Make the interface public and add a property for each of our repositories.  Next, add a requirement for a SaveChanges method that we'll define in the class that implements this interface.  Notice we only specified the "get" accessor such that we don't inadvertently overwrite an existing repository.  We want to make sure we leave all of the management of these repositories up to the Unit of Work class and not allow interference.



Next let's add a new class to the project called UnitOfWork.cs.  Make the class public and add the implementation of the IUnitOfWork class to the class declaration line.  Then select the Implement Interface option from the suggested fixes.



So far, we should be looking at the following:



If you recall, each of our repositories expects to receive an ApplicationDbContext as a parameter in their constructor and the Save Changes needs access to the database context to actually save any changes.  So, before defining each of these properties and the SaveChanges method, we need to create a constructor for this class and an instance of the ApplicationDbContext that we can save to a private field in the UnitOfWork class.  Something that should help us here is the ApplicationDbContextFactory, which we had already created in our ApplicationDbContext.cs file.



Now we have to implement the properties for each of the repositories the UnitOfWork will manage.  This should be as simple as creating a private field, checking if it is null, if so creating one and saving it to the field, then returning the field.  If it was previously created, then it will return the existing one.



And then follow through with the others.



Now we have the chore of implementing the method that will save all of the changes back to our database.



And, we are done with that, for now anyway.

I mentioned earlier in this post that we will need need to use this in dependency injection.  As such, we need to give the web application a heads-up that this will need created on the fly when it finds it in the constructor of our services.  We'll get into making services soon enough.  This "heads-up" is done in the Invoicing.API project's Startup.cs class.

Open up this class and look for the ConfigureServices method and add a reference to the the UnitOfWork class as a "singleton" to the list of available services for your application as shown below.  Adding the class as a singleton will ensure that each of the services we inject the UnitOfWork class into will receive the same instance of this class.  A little heavy duty on the terminology, but it will make much more sense once we create our first couple service.



And there we have it.  The UnitOfWork should be all setup for our first service.  In the next post we will work on setting up our first Controller.  Controllers represent the endpoints for our mobile application to connect and request data.