ASP.NET Core web project architecture (step by step guide) - Part 2 - Separation of the Web project, Business logic, Tests and Tools

 In this article is we will duscuss how to continue the separation of your project architecture in smaller independent parts. Just for reference in the first part of the article we talked about how to detach the web application from the database, which by default are comming in single project. If you have missed it, you can find it here.
 Now to the point. Why do we need to separate anything and make our lives harder?
  • Improved project orientaion and navigation - quick look at the project structure tells you where all different components are situated
  • Lower barrier for understanding - when introducing new people to some project that is already in progress it's always better to do that step by step. And when these components are well structured and neat it is easier to go through them
  • Improved maintenance - whether you have created the project from scratch or not, when a problem occurs it's a lot easier to define where this problem comes from
  • Easier extension of the project - having all the components separated makes it a lot easier to extend them

  If these are meaningful reasons for you, let's go on.
I will start with a bit of a Visual Studio misunderstanding in my opinion. it is called "New solution folder". As a have mentioned in the first part it shows a folder in the solution explorer, but it doesn't really create physical folder on the disk. Anyway lets add some solution folders.
...
Sample archicture
  • The data folder was here since we created it in the first part
  • Services - it is responsible for the containment of the business logic of the application as well as the tasks related to CRUD operations over the database.
  • Tests -Unit and integration tests
  • Tools - Here we might create different console apps like Crawlers, Importers and etc.
  • Web - The folder in which we will put the Web application together with an extention to for its infrastructure.
  Once we are ready with the solution folders lets fix the misunderstanding by manually creating the same folders in the file system.
...
 Now lets put the our Web Application to its place. In the Web folder. Again it is easier be done from the file system. Simple drag and drop will do the work.
...
Unfortunately this is not enough and we have to update the path in our .sln file . Again it's easy, just edit it with some text editor.
...
 Find the place where the web project is recorded and update the path with the "Web" folder prefix. It should look like that:
...

 Once we are ready with that we can restart our solution and check if everything is allright. If it is not you have probably missed some of the steps, but I think you will be just fine. The next step is to create some content in these empty folders. Lets start with adding a project which should be an extention to the web project. This project will contain the source code which is related to the Web application, but it is reusable, and this is why it is separated by the Web App.
...

 We call it {NameOfTheWbProject}.Infrastructure and should be put in the new Web Folder as it is shown on the image. It is regular class library as the rest of the projects which we are going to add to the other folders.
Similarly to the way of adding the Infrastructure project to the web folder lets add the fallowing projects:
  • Data -{NameOfTheWbProject}.Data (this is added in the first part)
  • Services - {NameOfTheWbProject}.Services, {NameOfTheWbProject}.Services.Data, {NameOfTheWbProject}.Services.Messaging - again all regular class libraries
  • Tools - {NameOfTheWbProject}.Console
  • Tests - some tests projects, but I think you got the idea
 When you are ready with that your solution should look something like that:
...
 And finally you would be able to keep your source code neet and clean, by adding a final library project called {NameOfTheWbProject}.Common with the intent to be added as a reference in each of the other projects. It's idea is to prevent the circular references, which might occur if we are adding some common logic in the other projects.
For example if we add let say some string extentions in the web project and after time we need them in the services, we won't be able to use them, because we would already have Reference from the services to the web project and adding reverse reference is not permitted.
So the solution is simple, just create another separate project for the common elements:
...
  As a conclusion I would say that this is just the second step of the creation of our extended architecture. We are getting closer to the desired architecture, but still far from ready and there is a lot to come in the next parts. In the part 3 we will discuss what to put in these empty projects with some examples.