Revisiting .NET Core Folder Structure for the second time
I enjoy writing. I also enjoy writing about my learning experiences. My personal goal is to write some code everyday. In addition to writing some code everyday I also want to share my learning experience. Sharing my learning experience through writing has at least two benefits. It helps me practice my writing skills — I feel the more I write the better the writing will become. Writing also helps me revise. I get to revisit the piece of code I wrote. By revisiting the code I wrote I think about it.
In a previous post I tried to think of the best way to organize my code. In the last year or so I have been trying to work through the eShopOnContainers project. I also realized in the process some things take time. I have not managed to get as far working through the solution as I would have wanted. But hey, you get up and try again. It is my feeling that you cannot work through a repository like this in a very short space of time. Too many concepts and ideas are contained in the solution. Ideally speaking you want to work through each concept/idea as thoroughly as possible. Rushing to the end goal means you are taking shortcuts. Humans are impatient, desiring immediate satisfaction. Yet lasting satisfaction takes time. It also means you have to consistent every day, or try to be. Okay I am getting carried away.
From today I thought I would try and rebuild the eShopOnContainers solution with an AWS flavour. In its current guise the solution is Azure-centric. Why not try and accomplish the same things using AWS? The learning experience will be tremendous. The eShopOnContainers solution covers a lot of areas. Microservices are built using a message broker. The microservices are dockerized — meaning I have a reference for .NET Core projects running in docker containers. The project also uses the Mediator pattern. It uses a mixture of data access libraries with good reasons — EFCore and Dapper. I have a strong desire to learn these things.
So lets look at the folder structure.
The solution is hosted on GitHub. It is a git repository. .vs appears to be Visual Studio Code files. Visual Studio Code is an extremely popular development tool. I’m not sure why it would be included? The build folder contains yaml files. The yaml files can be used in Azure Devops to configure builds. It is an approach I would consider using. Keeping build files in a git repository is a good idea. I’m not sure what the things inside the deploy folder does. The img folder contains images. Maybe specific to the solution? Would I keep images in a folder in that manner? Not sure what obj does. Obsolete appears to contain unused items. src and test contain code and tests for the solution. Generally speaking then tests should have its own folder. Tests should not live in the src folder. I notice the next two files are git specific — gitignore and gitattributes. I have no idea what gitattributes are. Documentation are saved as Markdown (md) files. The branch-guide, CONTRIBUTING and README files are Markdown files. README’s are standard documents in the root of a repo. The branch-guide appears to be specific to the solution. What does the NuGet file do? I have seen most projects not having a NuGet file.
“src” Folder Contains Visual Studio Solution Files
Something I was unsure about is the location of the sln file. Is keeping it in the src folder the correct place? The folder structure in the src folder appears to group code into functional areas. ApiGateways, BuildingBlocks, Mobile, Services, Tests and Web are different functional areas. I’m confused by the presence of the Tests folder. I am also confused by the presence of other test folders in other locations. The Services folder contains a Catalog folder. It contains two test projects — one for unit tests, another for functional tests.
Conclusion
I have a good idea of the general folder structure I want to follow:
- src — the code will go here
- test — should tests for the code go here? Or should tests appear at lower levels instead?
- build — yaml files will go here
- docs — documentation. A README will be created by default in the root of the solution
