I've worked for a few different development shops as well as worked on some independent consulting projects. One of the companies I've worked for is a fairly small development shop. One of their applications was a fat-client, WinForms application that has had little to no overarching project architectural work done to it. In helping rethink the architecture of their solution(s) and related data structures, we had a number of discussions and tried to factor in the skills/aptitudes of the current staff. We decided that our desired approach would be to create a ‘microservices’ architecture utilizing ASP.NET WebApi2 projects as our service endpoints. These will serve as our Business Logic Layer(BLL) allowing us to encapsulate all business rules/validations for the given object under development.
I had proposed a certain project structure for these BLL projects. After testing out some initial prototypes utilizing that structure and presenting it to the group, we decided that it would serve our needs well. The project structure we settled on was a follows:
- BusinessComponents.sln
- Apis/Apis.csproj: This project is the website that will actually expose the service through WebApi2 Controllers. Acting as the BLL, it also contains all of the validation logic for a resource(s) located at its endpoint.
- ApiClients/ApiClients.csproj: This project is a small project that wraps the Api project and allows us(through NuGet) to utilize a strongly typed client for communicating with its Api.
- Contracts/Contracts.csproj: This project contains the objects and interfaces that are exposed externally from this Api.
- DataAccess/DataAccess.csproj: This project contains all of the interactions that should take place between this Api its associated datastore.
- IntegrationTests/IntegrationTests.csproj: This project contains automated tests related to this Api. This suite of tests are responsible for setting up actual data in a datastore, calling the Api in relation to that data, validating its persistence in the datastore and its ability to be retrieved through its Api.
- UnitTests/UnitTests.csproj: This project contains automated tests related to this Api. This suite of tests test only one layer at a time and mocks out any other external dependencies to isolate the functionality under test.
We wanted to create a template for this project, as we hoped to be able to quickly generate these microservices. I decided to try to utilize Visual Studio’s project templating engine to accomplish this goal.
The main templating documentation page from Microsoft is located here. My goal was to be able to display a prompt to the user when they chose to create one of these projects to get some basic information about the project. Utilizing that information, I wanted the template to create as close to a buildable/runnable solution as possible that utilized our project structure and injected a number of custom values based off of the user’s input.
While I had very briefly tried my hand at creating templates before, I had been unsuccessful. Given this more dedicated block of time to work on it though, I was able to create a template and appreciate the tools that are in place to do so. There were a number of steps involved in this process and quite a number of gotchas along the way. I hope to record the process here and clarify some of the issues that tripped me up.