Project Background
During my professional career I developed many Asp .NET and .NET Core web applications, including static and
dynamic websites, and web APIs.
The APIs were following RESTful best practice and test driven development.
Layers
The APIs often relied on old legacy systems which were due to be replaced and developing an API on the top
of them was part of the strategy
to eventually replace the old systems. All APIs were built with several layers where a particular layer's
components were injected to the layer above.
API layer
The API layer was essentially the colleciton of the API controllers, which was the entry point for the
incoming requests. The controllers did not apply
any logic on the data, their only responsibility was to forward the request to the correct action, and
create the correct response returned by the API.
The correct http response was created depending on what was returned / thrown by the action layer.
Action layer
The actions built the request objects, applied validation on the request parameters (often through
validation classes) and retrieved the data
from different sources through the service layer. Since the API relied on several legacy systems, the
data often came through multiple services
for a single API call and POSTs and updates had to go through on multiple services too. For example
creating a repair request needed the creation
of a request, a work order, modyfing a legacy database entry, then getting the task list from the
created object for returning it to the controller.
Finally, the functions built the response objects that were converted to json by the controllers.
Service layer
The Service Layer functions were for warding the request to the correct third party service or
repository (database). The main purpose for this layer was to make replacing the old back-end system
easier. Since all layers were injected into the layer above, replacing a third party SOAP web service
would not require changing the actions.
Repository layer
This Layer acted as a wrapper around the databases (MsSQL and MySQL). The functions executed queries or
stored
procedures,
by using the popular Dapper Micro ORM. Earlier
Infrastructure
Originally the API was deployed to virtual servers running Ms Windows, via IIS and the unit tests were run
locally. When all tests passed the application was published via Visual Studio to the particular
server.
Later the server was replaced by a Linux Ubuntu server, and the application was deployed through docker.
This change made the deployment much faster, and changing the environment only needed change in the
environment variables. The logs were also saved on the Linux server to database that was also running as a
docker image.
Another API was built and deployed through Azure DevOps (VSTS) services. The code was using Git as source control, and every time when a commit was pushed to a branch, the application was automatically built. The unit and integration tests were ran as part of the build and only the successful builds were released into the particular environments.
Technologies Used
All APIs were implemented in C# with .NET Core or Asp .NET. The data was held in MsSQL or MySQL databases and the third party services were using SOAP web services or RESTful web APIs. xUnit and nUnit was used for unit and integration testing and Ms Windows or Linux with Docker for manual and Ms Azure for automatic deployment.
