Part 11 - Server Side Setup of a Service for your Mobile App

We are on one of the last part of our server side setup.  After this, much of the app production will be repeating a build process in which we can identify specific steps to add onto the mobile application.
The goal of this step is to create a home for our business logic and keep it separate from the API.  This will allow us to use the same business logic in other areas.  For example, say in the future we setup a separate client-side login in which clients can login to pay their invoices.  Or maybe we are working towards a suite of apps in which we want to leverage the same invoicing functionality, but don’t want to muddy up the API for our mobile app.

Open up Visual Studio 2017 to the Invoicing solution.  We will start by adding a base Service class under the Invoicing.Core project's Services folder.  Right-click on the Services folder and add a new class.  Name the class ServiceBase.cs.

Make the class public and add a protected field for the IUnitOfWork interface.  We'll need this in the majority of our services, so we’ll have this in here by default.



We need an AccountService now such that we can move our 'login' logic we had defined in the controller into this service and have the controller use this service to test the login credentials.  Since we will be using dependency injection to create this service, we'll need to create an interface for it as we had for the IUnitOfWork class.  Right-click on the Services folder and add a new interface named IAccountService.  Make sure we make the interface public such that it can be found from other classes.



Now we can create our AccountService and implement this interface and inherit from the ServiceBase class.



Add a controller that has a parameter for the IUnitOfWork interface such that dependency injection can create or pass in our singleton instance of the UnitOfWork class.



Now, we need to add the IAccountService to the Startup.cs class in the Invoicing.API project.  This will give the application a heads-up that this class will need dependency injection performed when it is encountered and providing instruction how it should be instantiated.

We'll add this as a scoped instance since we only want a maximum of one instance of this to be created per request.  If our app usage becomes higher or we have multiple users per "company" then we may want to change the IUnitOfWork to Scoped as well, but for now it is OK as a singleton.



Last, but not least, we'll move over the business logic we had placed in our AccountController.  I have identified our current business logic as the following highlighted section.



We'll first create a method stub in the IAccountService interface, and then we can implement the interface to add the method to the service with the above logic.





Now, we need to inject the AccountService via the controller's constructor and save it to a field in the class so we can use it in our Login method.



And… there it is!

This pretty much wraps up our server side setup.  Now that people can login… it seems we had forgotten a way for people to actually signup!  In the next post, we will go through from start to finish using everything we have learned to create a new component and actually use the database we worked so hard to setup.